> > Besides, what would be the alternative, BEGIN{} - like blocks?
> 
> Such blocks are put forth as an alternative:

Well, remember that BEGIN{} blocks are just subs too, with an optional
'sub'.

But that aside, I don't think a block is what we want to connote. A
block implies "this is evaluated here", not "this is a member method".
That's a sub. Maybe a special sub, like DESTROY, but it's still just a
sub.

> Being able to call these as normal methods may be desirable, or it may not
> be.  Personally, I will likely never call $spot->PREPARE, just as I never
> call tied(%ixhash)->STORE("foo" => "bar"). 

I want to be able to. I call ->STORE and ->DESTROY all the time, because
it's faster than having to go through tie:

   $object = tie %ignoreme, 'Some::Class';
   $object->STORE('key', 'val');
   $object->DESTROY;

> So the object would be left undefined?  That means this code:

No, not at all. Remember, everything's going to inherit from CORE, at
the very least, which would have to provide a CREATE method which just
instantiates a simple object. So, if no Dog::CREATE exists, then $spot
becomes a regular old scalar. I see many many uses for this. For
example, maybe you have a class that you just want to add a STRING sub
to, so it prints out nice. Forcing a CREATE sub to be defined here is a
needless restriction.
 
> However, consider existing tied classes, for example IO::File; it must
> provide duplicate methods, lowercase for users, uppercase for the tied
> interface.  Would it really be less consistent or readable if, say, the
> getline() method was able to be called when a user said either <$fh>, or
> $fh->getline?

I'll soon have an RFC coming up that proposes a way to "fix" this, but
implements it differently. I think you'll like it.

I disagree vehemently that users should be able to name all this stuff.
If they're really bothered by it, that's what typeglobs are for.
Infinite flexibility == Infinite confusion. And I don't think simply
choosing variable and sub names counts as dictating style. So on this
point you and I will have to disagree.

-Nate

Reply via email to