Post #190,723
1/19/05 12:10:24 AM
|
Gruh?
> Remember that time I was playing with Python and Tk graphics
> and used a string with a function name instead of a function
> pointer in a call-back and youses jumped all over me for trying
> to interchange the two?
No.
> In a truly dynamic language it should not matter. If one does
> arithmentic on a series of variables, such as x = a + b + c,
> and "c" happens to be a string such as "69", then it should
> automatically convert, or interpret it as a number.
That's an awful lot of "should's" for someone who's never designed a language.
> If it does this with numbers, why not function pointers?
1. It doesn't "do this" with numbers.
2. There's no such thing as a function pointer.
Read [link|http://effbot.org/zone/python-objects.htm|http://effbot.org/zo...ython-objects.htm]
> Python seems to have a half-ass typing system where
> there is a hidden "type" indicator/flag associated
> with each variable.
Not at all. It's quite accessible. Try inspecting type(a) or b.__class__
> Sometimes it will ignore/bypass this
It's never *ignored*. Errors should not pass silently.
> A dynamic language should use only context
> and not a hidden type flag.
1. Again, it's not hidden, and
2. Relying on context is what gets you into "annoying", "inconsistent" (dare I say) "magical" runtime evaluation.
|
Post #191,397
1/24/05 3:41:04 PM
|
Another language fight?
That's an awful lot of "should's" for someone who's never designed a language.
Would it change anything if I built a language that had the features I wanted? It would probably resemble Tcl in many ways.
It's never *ignored*. Errors should not pass silently
Well, in that case it did. Maybe it was a bug in the Tk library or the adapters, but it silently ignored it.
[there is a hidden "type" indicator/flag associated
with each variable.] Not at all. It's quite accessible. Try inspecting type(a) or b.__class__
I didn't mean it was undeterminable. "Hidden" and undeterminable are two different things. My pet language would not have ANY hidden "type" indicators, by the way.
Relying on context is what gets you into "annoying", "inconsistent" (dare I say) "magical" runtime evaluation.
Not if you don't overload the operators. And responding to a nearby comment about it being common, so is COBOL. But that does not make it "good". The masses are often idiots. The election proved that.
There's no such thing as a function pointer.
Whatever "it" was, it was not interchangable with a string containing the function name.
________________
oop.ismad.com
|
Post #191,403
1/24/05 4:47:45 PM
1/24/05 6:09:03 PM
|
What is there to fight about?
Tcl is over there --> Every comment you make comes down to "I want language aspect _____ to be implicit". One of the core design principles of Python is "Explicit is better than implicit". Either you agree with that design philosophy, or you go find another language--there's no fight to be had. Python's not going to change to meet your list of "should's" for "a dynamic language". There's no such thing as a function pointer.
Whatever "it" was, it was not interchangable with a string containing the function name. Which might lead one to believe that there's a good reason "it" is not interchangable with the string. Don't know what "it" really is? Find out first, then critique. The page I pointed you to is a good start--like any language, Python has fundamental differences from those with which you are familiar. The binding of names to objects is probably the first and most significant hurdle to Python newbies, and is exactly what that link talks about, and is exactly what you're stumbling over with the function name issue. The fact that you then tie this in to operator overloading is completely orthogonal (except that, in both cases, you seem to want the language to guess in the absence of information).
Edited by FuManChu
Jan. 24, 2005, 06:09:03 PM EST
|
Post #191,415
1/24/05 5:33:49 PM
|
Explicit is definitely what Python is about
And the main reason I prefer it to Perl.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #191,968
1/27/05 1:12:22 PM
|
Name and pointer unnecessary duplication
A function name and pointer are generally duplicated references to the same information. You essentially have 2 primary keys. Now maybe it is done for speed, but otherwise is a sloppy or compromized theoretical arrangment.
except that, in both cases, you seem to want the language to guess in the absence of information
There is no need for "guessing" if the duplication is removed.
________________
oop.ismad.com
|
Post #191,977
1/27/05 1:48:33 PM
|
No, it isn't duplicated.
The function "pointer" is actually an object that contains a lot more information than a simple string can convey.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #192,160
1/28/05 7:27:07 PM
|
references versus the record itself
The function "pointer" is actually an object that contains a lot more information than a simple string can convey.
The string is like an ID that points to (references) a record, not the record itself. If it requires more, then make it an associative array, but I don't see a need for that so far either.
Someone below suggested that more is needed to implement closures. Personally I have not seen a slam-dunk justification for closures. They may simplify code a few percent at most. We had a huge debate here about this once and I see no need to repeat it again.
________________
oop.ismad.com
|
Post #192,003
1/27/05 2:54:20 PM
|
...and the duplication is necessary.
Once you realize that it's not just 2 copies, but n copies. In this way, you can have multiple bindings to the same object, to be used in different descriptive contexts (with its own semantics tht map to the appropriate problem domain). A local namespace can have a named reference to the object. A list can have an anonymous, but indexed, reference to the object. A hashmap/dictionary can possess a named reference which approaches worst-case O(n) lookup on the *name*, instead of on the value (the function pointer).
In other words, there's a reason we use variable names instead of register or memory addresses.
|
Post #192,054
1/27/05 11:34:17 PM
|
You clearly do not know what a closure is
If you can figure out the following piece of code, then you'll understand how there can be many different copies of a function, all slightly distinct. \nuse strict;\n\nnested_for(\n sub {print "@_\\n";},\n [1..2], ['a'..'c'], ['A'..'D']\n);\n\nsub nested_for {\n ret_iter(@_)->();\n}\n\nsub ret_iter {\n my $fn = shift;\n my $range = shift;\n my $sub = sub {$fn->($_, @_) for @$range};\n return @_ ? ret_iter($sub, @_) : $sub;\n}\nCheers, Ben I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
