> And attributes are essentially member variables of objects, which you
> can access as "$obj.foo".  Another possible description of 
> them might be
> lvalue methods which never take arguments, and which fetch and store
> class-specific pieces of data.  Different classes may define their own
> private ".foo" attribute, and these will be distinct even if a class
> inherits from two classes who both have a .foo attribute.
> 
> In perl5, attributes are roughly implemented by class instances being
> blessed hash members, and if more than one class uses a particular
> member name, they will end up colliding.
> 


Well, we aren't continuing that (collisions), are we?

Mapping attributes to   $object{package}:attribute="no clobber!"   fixes
that.

my %attribs_from_package_a = %object{package_A}    #might return
('MY::package_A::A' => 1,
                                                   #
'MY::package_A::Z' => 2)

my %variety_of_attribute_a = %object:attribute_A   #might return
('MY::package_a::a' => 1,
                                                   #
'DEF::GHI::A'      => 2 )

my %all_attribs            = %object{}             #might return
('DEF::GHI::A'      => 2,
                                                   #
'MY::package_a::A' => 2,
                                                   #
'MY::package_a::Z' => 2)

I suppose 
my %all_attribs_no_package = %object{undef?}; #would return (A=>2,Z=>2) or
(A=>1,Z=>2)

This maps 1 to 1 with the XMLNS recommendation.






------------------------------------------------------------------------------
This message is intended only for the personal and confidential use of the designated 
recipient(s) named above.  If you are not the intended recipient of this message you 
are hereby notified that any review, dissemination, distribution or copying of this 
message is strictly prohibited.  This communication is for information purposes only 
and should not be regarded as an offer to sell or as a solicitation of an offer to buy 
any financial product, an official confirmation of any transaction, or as an official 
statement of Lehman Brothers.  Email transmission cannot be guaranteed to be secure or 
error-free.  Therefore, we do not represent that this information is complete or 
accurate and it should not be relied upon as such.  All information is subject to 
change without notice.


Reply via email to