develooper Front page | perl.perl5.porters | Postings from August 2021

Re: Twigils

Thread Previous | Thread Next
From:
Darren Duncan
Date:
August 13, 2021 09:55
Subject:
Re: Twigils
Message ID:
fde3a137-2007-f7ed-7dc7-2b81fd7ad904@darrenduncan.net
On 2021-08-13 2:18 a.m., Veesh Goldman wrote:
> I think the idea of accessing $other's slots is debatable, and shouldn't be used 
> as a driving factor in this syntax discussion.
> In my opinion, anyway, we shouldn't have a default way to access members of 
> other objects. If that sort of sharing is needed, it should be explicit with its 
> own interface.

How is accessing the slots of $other which is of the SAME CLASS debatable?  That 
is a completely normal and commonly done thing and is what every single other 
language in existence (that I know of) does.

If you didn't have that, how would you code the interaction of 2 objects of the 
same class by way of internals that code in other classes isn't supposed to see 
and hence no :reader or :writer exists?

Now I can understand Corinna having a feature different from other languages 
such that it is even more restrictive, however then we need to provide a way to 
grant permission to see slots of other objects of the same class.

This then comes back to the proposal I made months ago where something akin to 
Raku's "trusts" feature is important, where a class can enumerate what classes 
can access their otherwise private things, and in this case one would declare 
that a class trusts itself.

-- Darren Duncan

> On Fri, Aug 13, 2021, 12:13 Darren Duncan wrote:
> 
>     On 2021-08-13 1:02 a.m., Tom Molesworth via perl5-porters wrote:
>      > On Fri, 13 Aug 2021 at 15:59, Darren Duncan wrote:
>      >     I believe the best way to design this is to do something that
>     directly mirrors
>      >     the current blessed hashref approach, which is that you ALWAYS
>     reference a slot
>      >     in terms of a subscript of an object of the type.
>      >
>      > Strong disagreement from me on this - after using Object::Pad for a
>     while, it's
>      > painful to go back to the old approaches.
>      >
>      > Slot access is a common operation, so I find the single-character Huffman
>      > encoding we have now to be an excellent fit.
> 
>     I don't have a problem with the single character Huffman coding as an
>     ADDITIONAL
>     option.  But it needs to be in ADDITION to something like what I proposed,
>     because that Huffman option itself only gives access to slots for a single
>     object of the current class while mine works for all objects of the current
>     class. -- Darren Duncan
> 


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About