Front page | perl.perl5.porters |
Postings from June 2022
Re: Pre-RFC: namespace literal as first class citizen
Thread Previous
From:
Darren Duncan
Date:
June 30, 2022 08:07
Subject:
Re: Pre-RFC: namespace literal as first class citizen
Message ID:
14cb3951-dec6-9c54-d27a-041c88e8e28c@darrenduncan.net
On 2022-06-29 11:34 p.m., Branislav ZahradnĂk wrote:
> Idea:
> Introduce namespace literal into language with it's own ref type and so.
>
> Current state:
> - any string when used as a reference in method invocation is treated as namespace
> - language already supports trailing :: syntax, producing string without ::, and
> warning, when namespace is not available yet
>
> Other languages examples:
> - Java and their java.lang.Class (or .class attribute)
As it happens, I already invented a corresponding portable data type or possible
representation called "Nesting" in my Muldis Object Notation / Muldis Data Language.
A "Nesting" is isomorphic to an array of 0..N character strings and has a
literal syntax that looks like a Perl multi-level fully-qualified package name,
such as "::Foo" or "Foo::Bar" or "Foo::Bar::Baz" etc, and it is intended to map
to the same, or to the analogy in other languages.
A "Nesting" is also classified as a non-collective or terminal type, like
booleans/numbers/character strings/blobs/etc, and unlike arrays/associative
arrays/etc.
A "Nesting" is also used to represent a lookup or address into a nested
collection type such as a Perl hash of Perl hashes of Perl hashes etc
arbitrarily deep, and could also be used in an extension to a Perl hash literal
to declare such, for example, these 2 tentative Perl expressions are equivalent
/ produce the same hash ref with a hash ref element:
{
x1 => 3,
x2::y1 => 4,
x2::y2 => 5,
x3 => 6,
}
{
x1 => 3,
x2 => {
y1 => 4,
y2 => 5,
},
x3 => 6,
}
So what has this taught me about what may be good as a namespace literal in Perl?
First, while I could take it or leave it, I would lean towards the namespace
literal NOT being a Perl ref type, but rather a Perl scalar type. That's less
likely to be surprising.
Syntactically, existing Perl programs could get this for free under newer Perls
because the literal syntax is identical to how package names are now, at least
if they had the "::" in them, or even if they don't, if we have a bareword
followed by a "->" then we know it is this too.
Perhaps to maximize backwards compatibility and minimize changes, this could be
implemented as a regular Perl character string but have some extra internal flag
similar to the "created as boolean" (name?) or such flags.
For serializer/deserializer purposes, similar to the internal flags to treat
booleans and numbers and strings as disjoint so they round trip through JSON or
other formats, the marker can result in package names being mutually disjoint
with all of those, and then supporting serialization formats such as mine can
exploit it.
Anyway, this is just ideas I'm putting out there, I'm not really trying to push
it at this time.
-- Darren Duncan
Thread Previous