Post #113,972
8/16/03 4:05:07 AM
8/16/03 4:08:51 AM
|
another solution
I have kicked around the idea of simulated named parameters using a string. Example:
href('Forums', 'z.iwethey.org', ''); // no extra params
href('Forums', 'z.iwethey.org', 'underline=no, target="_blank"');
Inside we could then have a standard function(s) that parses out the value:
function href($title, $url, $namedParams) {
....
$target = getParam($namedParams, 'target');
if (! empty($target)) {....}
....
} // end-func
However, the parsing may slow things down. But for typical intranets it may be fine.
________________
oop.ismad.com
Edited by tablizer
Aug. 16, 2003, 04:06:45 AM EDT
Edited by tablizer
Aug. 16, 2003, 04:08:51 AM EDT
|
Post #113,981
8/16/03 7:53:22 AM
|
No, it's not.
In fact, it's slightly worse. The string parsing required would be a significant drawback; in ease-of-use, in efficiency and in concept. FWIW, the PHP equivalent in my approach to that would be:
href('Forums', 'z.iwethey.org', array('underline' => false, 'target' => "_blank");
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #114,452
8/19/03 11:49:09 PM
|
That is more syntax
My approach is only 2 more characters than native named params. Yours is at least a dozen more. Slower? Yes, I agree. But it depends on the environment whether speed is the bottleneck or harder-to-read code.
________________
oop.ismad.com
|
Post #114,454
8/19/03 11:50:34 PM
|
OT: Bryce...
Send me your information... I got the BOOK!
--
[link|mailto:greg@gregfolkert.net|greg],
[link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
[insert witty saying here]
|
Post #115,176
8/24/03 2:03:40 PM
8/24/03 2:06:08 PM
|
OT: I don't have access to receipt. On biz travel
Okay with me to assume stamped postage value.
________________
oop.ismad.com
Edited by tablizer
Aug. 24, 2003, 02:06:08 PM EDT
|
Post #114,573
8/20/03 1:30:02 PM
|
Also more limited
The string approach is also limited to literal values. Variables would have to be interpolated into the string (easy or not, depending on the language), but even then would only work with values that can be reliably converted to a string and back.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #114,590
8/20/03 2:40:14 PM
|
There be XML
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #115,179
8/24/03 2:13:45 PM
|
but XML "solves" the problem by not having variables
________________
oop.ismad.com
|
Post #115,178
8/24/03 2:12:53 PM
8/24/03 2:15:27 PM
|
minor issues IMO
The string approach is also limited to literal values. Variables would have to be interpolated into the string (easy or not, depending on the language)
PHP makes variable insertion easy. Example:
$bar = "glog";
foo($x, $y, $z, "myvar=$bar");
Of course, if you are passing something more complex than a variable, this may not be so easy. But, if you are passing an array, then a dedicated parameter is probably the way to go. Or, just pass SQL needed to retreive the info.
but even then would only work with values that can be reliably converted to a string and back.
Being that I tend to put complex structures in the database instead of code thingies, this is usually not a problem for me.
________________
oop.ismad.com
Edited by tablizer
Aug. 24, 2003, 02:15:27 PM EDT
|
Post #115,262
8/25/03 5:58:10 AM
8/25/03 6:02:24 AM
|
I should have known.
This is not actually for your benefit, Bryce, but it looks to me that you just didn't get my point about how I've implemented named parameters. I'm not surprised, really.
Wade.
P.S. Oh yeah: don't take this the wrong way! :-) It's just that by this point in a conversation, experience has taught me that if you haven't gotten the original point, it's a waste of time trying to get you to see it.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
Edited by static
Aug. 25, 2003, 06:02:24 AM EDT
|
Post #115,326
8/25/03 4:54:32 PM
|
Re: minor issues IMO
Jim: but even then would only work with values that can be reliably converted to a string and back.
Tablizer: Being that I tend to put complex structures in the database instead of code thingies, this is usually not a problem for me.
Things that cannot be converted to a string and back are usually the types of things that cannot be stored in a database. I'm thinking of open file connections, database connections, connection pools, procedure objects, semaphores, sockets, threads, mutexs, execution contexts, continuations, etc.
All of the above could easily be passed in an array or hash.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #115,511
8/27/03 2:31:45 AM
|
difference in style
Things that cannot be converted to a string and back are usually the types of things that cannot be stored in a database. I'm thinking of open file connections, database connections, connection pools, procedure objects, semaphores, sockets, threads, mutexs, execution contexts, continuations, etc.
I suppose it depends on how the language works. In some langs/libs things like file connections and database connections were simply integers (ID's). The language kept a list (table?) of open "things". If there was a crash or shut-down, the list would be traversed and items closed.
I suppose in my ideal language and environment, EVERYTHING would be a table (surprise surprise). Thus, "complex structures" would be things like queries (strings) or ID's. Generally you reference the complex thing or service rather than pass it around as a RAM lump.
But tablisms aside, I don't generally find a need to put those kinds of things in named parameters for some reason. Named parameters are generally for "tweaks" rather than some complex structure by itself. I agree that arrays are more flexible, but like I said before, they are more wordy in calls. Given the tradeoffs, I would take less code. The few things that need complex RAM thingies down the road simply get a new fixed-position parameter, even if it requires finding and fixing existing calls. I doubt it would happen enough to justify more syntax. That is my weigh-in. Take it or leave it. (Assuming lack of real named params.)
________________
oop.ismad.com
|
