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