>
> Now look at eval. When acting on a string, it compiles and runs it as
> code. When acting on a block, it traps any errors and prevents dying.
> You may be able to come up with some weak analogies between the two,
> but they're two different functionalities.
i have nothing to add. you obviosly want to scrap eval-block for try.
This is turning into a religious dispute.
> Different object, same action: ok
> Different object, different action: not ok
>
> > close (IO) # closes an open stream, returns
> > # true on success or false on failure,
> > # sets $! on failure
> >
> > close (\$) # overwrites the ASSIGN method of the
> <overly elaborate explaination snipped>
>
> close. Closing a filehandle means you're no longer going to read
> and/or write to it (depending on how it was opened). Closing a
> variable means you're no longer going to write to it... but reading is
> ok. The analogy is there, but its not a particularly strong or
> obvious one, and there's the jarring difference that you can no longer
> read from a closed filehandle, but you can read from a closed variable.
> You've got to be careful with polymorphism and ensure that you've got
> strong analogous action in all cases. Not just because its clever or
> you like the name. This is not to say we shouldn't have polymorphic
> built-ins (we already have more than you might think) but they must be
> chosen with extreme care.
So I take it that you object wholeheartedly to C++ Streams libraries
using << and >> for IO operations because even though there is never any
confusion, since bitshifting file handles is silly, it is in your terms
WRONG?
I think the limited set of objects that close(filehandle) is defined on
makes it a perfect candidate for overloading with something completely
different, just like the bitshift operators were overloaded for file
ops in C++. I will continue to use it as described in discussion of
How Capabilities Might Work In This Context until whacked over the head
with a better keyword.
> Some more counter-examples... un/pack() on a filehandle could compress
> and decompress the file! It might be perfectly logical if un/pack
> didn't already do something completely different.
>
> Some good examples... delete/exists work on both arrays and hashes.
> delete() completely removes an array/hash element, exists() checks to
> see if an array/hash element has been populated (even if its
> undefined). The details might start to diverge a bit, but the basic
> meaning doesn't change.
>
> Homogeneous operators are potentially confusing (just because English
> has homonyms doesn't mean its not confusing) but not all polymorphic
> functions are homonyms. Find the ones which retain their basic
> meaning across all their objects, those are the good ones.
>
> PS delete() and exists() are also polymorphic, as is reverse(),
> chomp(), chop(), goto() and die(). There are probably more, but I
> can't think of them, probably because they mesh so well we don't even
> think about it. You could consider functions which have default
> arguments as polymorphic, then there's lots and lots of polymorphism
> in Perl. But I digress.
Great! So you agree that we need better polymorphism in prototype and
dispatch of user-defined routines?
--
David Nicol 816.235.1187
Signature closed for repaving
