I can only agree with your wisdom.
Neither would I pay the 100x speed down for nothing.

However, the fact that we rarely use class late binding is not a proof 
it wouldn't be usefull. Maybe we don't use it because we are not used to it.

Beside the good Undeclared example of Paolo, it could for example enable 
executing some code safely by changing all dangerous class references 
with secured restricted versions. Certainly easier if late bound.

I think most applications would occur when playing with packages 
loading/unloading/ replacing with an experimental version, or maybe 
implementing an auto-loading feature more easily.

Note that VW has introduced a special syntax for late binding 
#{ThisIsALateBindingExample}.
This must be to accomodate increased complexity brought by namespaces I 
guess and/or the loading of Parcels/Packages.
That's precisely the point. Scaling up the image, imitating what the OS 
does with applications and libraries. There could lie the major use of 
late binding.

Whether we should or not follow this path is another debate.
You can deplore that "Small"talk is getting too big, and is loosing its 
soul: code is becoming less factored. With more than 2000 classes, the 
probability for rewriting some code already in the image is for sure 
greater than with 200.
See the enlightening example of Net::etc...::Socket duplication from the 
namespace thread...

That's a fact. Image is growing.
Pushing more packages out is likely to create more problem than solved, 
more duplication, less factoring, thus the namespace debate and its 
class-late-binding avatar...


Andreas Raab a écrit :
> nicolas cellier wrote:
>> Funny Andreas, we could have said exactly the same about messages...
>> Sure a lot of curly brace defenders have already.
> 
> Not quite. There are various real problems that you can only solve via 
> late-binding method names to their implementations (inheritance for 
> example makes little sense if you need to know whether you're going to 
> call a function with an Orange or an Apple instead of just generally 
> using a Fruit). Whether using late-binding *exclusively* solves any real 
> problem I'm personally not so sure. There have been numerous times where 
> I wished to have the ability to early-bind methods and rather recompile 
> everything upon a change instead of being forced to use late-binding (we 
> pay a major price for this; both in terms of runtime and development 
> costs because in the case where we need it we have to punt and use C 
> instead).
> 
> But late-binding class names? I'm sorry, but I really fail to see which 
> problem this is supposed to address (and I have the distinct feeling 
> neither do you because otherwise you probably would have pointed out at 
> least one good reason why it is advantageous ;-) Besides, I would like 
> to point out that we often use late-bound classes already (browse those 
> implementors of #controllerClass in MVC) and that classes are 
> automatically kept up-to-date (which would be a good reason for 
> late-binding them otherwise). And as if that weren't enough you can just 
> assign them if you'd like to use some other class instead. So, once 
> again, what is the advantage of late-binding class names? And how does 
> it outweigh the price you'd have to pay?
> 
>> From a pragmatical POV, you're probably right.
>> But from a historical, not sure...
>> Be a future VM able to transparently inline those lookups, that your 
>> arguments might vanish.
> 
> In which case I'll happily late-bind them. Because if there is no cost 
> associated with it then there's really no reason not to (outside 
> security). I have no general problem with late-binding class names 
> (security concerns excluded) but given the price, I'd like to know why 
> exactly I should be paying it.
> 
> Cheers,
>   - Andreas
> 
> 
>