develooper Front page | perl.perl5.porters | Postings from May 2000

Re: overloading = [a solution]

Ilya Zakharevich
May 6, 2000 17:53
Re: overloading = [a solution]
Message ID:
On Sun, May 07, 2000 at 08:25:41AM +1000, Damian Conway wrote:
>    > So it is essentially of the same degree of complexity as tie()ing.
> Perhaps to someone as clever and knowledgeable as yourself. But to most
> people, writing:
> 	classify $var => 'ClassName';
> is considerably less complex than writing a nontrivial package and tie()ing
> a scalar to it.

Sorry, but I will not listen to such statements from the designer of API.  ;-)

>    > > And the tie()d version *still* doesn't support per-object assignment
>    > > semantics, dispatch to ASSIGN without type-enforcement,
>    > 
>    > Of course it does.  ASSIGN is just a shell for STORE.
> It didn't support those things as it was written but, yes, of course it
> *could* support them with extra the expense of making the
> STORE even more complex.

Or less complex, depending on your target.

> Of course. My point was that the complexity of the tie() mechanism (and yes,
> for many folks back in the Real World, tie() is firmly in the Too Hard basket)
> makes people not want to learn it. Hence they are unable to whip up a custom
> TIESCALAR/FETCH/STORE suite when they need it.

Two APIs are of *almost* the same complexity, so this is not an
argument.  However, if you want to sell your approach, I would not
concentrate on complexity of API, but on the point *who* provides *what*.

tie() and PREPARE would be most probably used by the *designers* of the
classes in question.  While your interface is targeted to *users* of the
classes.  The users may want to use some third-party (yours ;-) tools
to provide a consistent way to "declare" "class"iness of their variables.

But this goes closer to the CORE now than to a module.

  my Dog $foo :confine;

Ilya Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About