Damian Conway writes: > My API: > > use Class::ifiedVars; > > classify $spot => 'Dog'; > classify $fluff => 'Cat'; > classify $rex => 'Tyrannosaur'; > > type AlleyCat => 'AlleyCat' > AlleyCat ($felix, $tom, $snagglepuss); But you also need ASSIGN for any reasonable situation. > Tie()ing: > > package Tie::OneTypeOnly; > > sub TIESCALAR { bless { type => $_[1] }, $_[0] } > sub FETCH { $_[0]->{value} } > sub STORE { my $newtype = ref $_[1]; > croak "Can't assign $newtype to $_[0]->{type} var" > unless $newtype->isa($_[0]->{type}); > return $_[0]->ASSIGN($_[1]) > if ($_[0] && $_[0]->can('ASSIGN'); > $_[0]->{value} = $_[1]; > } > > tie $spot, 'Tie::OneTypeOnly', 'Dog'; > tie $fluff, 'Tie::OneTypeOnly', 'Cat'; > tie $rex, 'Tie::OneTypeOnly', 'Tyrannosaur'; > tie $felix, 'Tie::OneTypeOnly', 'AlleyCat'; > tie $tom, 'Tie::OneTypeOnly', 'AlleyCat'; > tie $snagglepuss, 'Tie::OneTypeOnly', 'AlleyCat'; So it is essentially of the same degree of complexity as tie()ing. > 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. > or use by people who don't (want to) know about tie()ing. But your package does not support use by people who don't (want to) know about your package. And given that tie() is so much more useful than your package, it is a killer argument. IlyaThread Previous | Thread Next