Front page | perl.perl5.porters |
Postings from May 2000
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 coding...at 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