Ticket #903 (new RFC)

Opened 5 years ago

Last modified 3 years ago

[RFC] Deprecate Keys at all.

Reported by: bacek Owned by:
Priority: normal Milestone: 2.6
Component: core Version: trunk
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:

Description

Hello.

(Background: I've spent few months trying to make Keys and Iterators more sane)

There is excerpt from IRC log:

<bacek> chromatic: I've got excellent (fsvo) idea. Deprecate Keys at all.
<chromatic> What would replace them?
<bacek> Create NamespaceKey which will be used for Namespaces.
<bacek> Navigating over "ordinary" aggregates will be "manual"
<chromatic> The idea has merit.
<bacek> indeed.
 No one uses $P0[foo;bar;baz]
 It's almost impossible to implement and used correctly.
 And behaviour is very dependant on HLL
<chromatic> It's not easy to manage in IMCC either.
<bacek> e.g. autovivify vs throwing exception.
 So, NamespaceKey will has-a RSA
 Simple, clean, comprehensible.
 Remove a lot of code in Hash and Array to support Keys.
 Simplify IMCC and future of PIRC (which doesn't support complex keys)
<chromatic> It's worth considering.

Actually NamespaceKey can be is-a RSA. Then creating it in pir will be something like

   $P0 = split ';', 'foo;bar;baz'
   $P1 = new [NamespaceKey]
   $P1 = $P0

-- Bacek

Change History

in reply to: ↑ description ; follow-up: ↓ 2   Changed 5 years ago by pmichaud

Replying to bacek:

... Actually NamespaceKey can be is-a RSA. Then creating it in pir will be something like {{{ $P0 = split ';', 'foo;bar;baz' $P1 = new [NamespaceKey] $P1 = $P0 }}}

Note that this last statement cannot be correct -- it would simply create a NamespaceKey and then throw it away as $P1 is set to the RSA returned from the split.

I suspect you mean "assign $P1, $P0" here.

Also, I hope this is only intended as a mechanism for creating NamespaceKey objects at runtime -- clearly we would expect ['foo';'bar';'baz'] to work as a constant namespace key in PIR.

Pm

No. If you require this then you're taking something that is currently a compile-time constant and turning it into a runtime operation (and creating N+2 GCables).

Please make sure that we can continue to do

in reply to: ↑ 1   Changed 5 years ago by bacek

Replying to pmichaud:

Note that this last statement cannot be correct -- it would simply create a NamespaceKey and then throw it away as $P1 is set to the RSA returned from the split. I suspect you mean "assign $P1, $P0" here.

Ah. yes. My mistake.

Also, I hope this is only intended as a mechanism for creating NamespaceKey objects at runtime -- clearly we would expect ['foo';'bar';'baz'] to work as a constant namespace key in PIR.

Correct. Example PIR is additional mechanism for creating NamespaceKeys in run-time. IMCC/PIRC/* will emit constant PMC during compilation.

No. If you require this then you're taking something that is currently a compile-time constant and turning it into a runtime operation (and creating N+2 GCables). Please make sure that we can continue to do

Yes.

Main idea to remove Keys for navigating over ordinary Hashes/Arrays. Namespace will stay almost same. Keys became NamespaceKeys but with string parts only.

-- Bacek

follow-up: ↓ 5   Changed 5 years ago by allison

I'm okay with eliminating the Key PMC, but not the ['foo';'bar';'baz'] syntax. It's too useful. And, a custom NamespaceKey PMC is unnecessary, when all we really need is a FixedStringArray. This will have to wait until after 2.0, since it's a substantial deprecation.

  • Continue to parse ['foo';'bar';'baz'] everywhere it's currently parsed, but generate a FSA instead of a Key.
  • When used with and array or hash, ($I0 = $P0['foo';'bar'] or $P0['foo';'bar'] = $I0) they still call get_*_keyed' or 'set_*_keyed', but they pass it a simple FSA. Each PMC is free to decide how to handle array PMC keys internally (even flattening them into a single string "foo\0bar\0baz", if it wants to).
  • The NameSpace PMCs will continue to treat them as they currently treat keys and arrays, as multi-level access to the namespace tree. But, it can simplify the code, since all complex keys will be arrays.
  • Do away with KEY types in opcodes (they're just PMCs). Any op that can be called with a key can be called equally well with another array PMC.
  • Make it possible to use key syntax on the LHS of assignment, as a cheap way to create a constant FSA:
    $P0 = ['foo';'bar';'baz']
    
  • These could be used to initialize PMCs:
    $P0 = ['key1';'value1';'key2';'value2']
    $P1 = new "Frobisher", $P0
    # or even:
    $P1 = new "Frobisher", ['key1';'value1';'key2';'value2']
    

  Changed 5 years ago by allison

s/and/an/ s/LHS/RHS/

in reply to: ↑ 3   Changed 5 years ago by bacek

  • component changed from none to core
  • milestone set to 2.6

Replying to allison:

I'm okay with eliminating the Key PMC, but not the ['foo';'bar';'baz'] syntax. It's too useful. And, a custom NamespaceKey PMC is unnecessary, when all we really need is a FixedStringArray. This will have to wait until after 2.0, since it's a substantial deprecation.

Yes. We have to wait until after 2.0.

* Continue to parse ['foo';'bar';'baz'] everywhere it's currently parsed, but generate a FSA instead of a Key.

Agreed.

* When used with and array or hash, ($I0 = $P0['foo';'bar'] or $P0['foo';'bar'] = $I0) they still call get_*_keyed' or 'set_*_keyed', but they pass it a simple FSA. Each PMC is free to decide how to handle array PMC keys internally (even flattening them into a single string "foo\0bar\0baz", if it wants to).

Slightly disagree. We can deprecate current handling of "Keys" in Hashes/Arrays and add get_hashvalue VTABLE function to unified support of non-string keys.

* The NameSpace PMCs will continue to treat them as they currently treat keys and arrays, as multi-level access to the namespace tree. But, it can simplify the code, since all complex keys will be arrays.

Indeed.

* Do away with KEY types in opcodes (they're just PMCs). Any op that can be called with a key can be called equally well with another array PMC.

Agreed.

* Make it possible to use key syntax on the LHS of assignment, as a cheap way to create a constant FSA: {{{ $P0 = ['foo';'bar';'baz'] }}} * These could be used to initialize PMCs: {{{ $P0 = ['key1';'value1';'key2';'value2'] $P1 = new "Frobisher", $P0 # or even: $P1 = new "Frobisher", ['key1';'value1';'key2';'value2'] }}}

Why swap arguments in new?

-- Bacek

follow-up: ↓ 7   Changed 5 years ago by whiteknight

as a general note, not even entirely related to this ticket, if we are parsing ['foo','bar','baz'] as an FSA, I think it might be a good opportunity to consider using similar syntax to specify multiple types of PMC aggregate literals also. So [1,2,3,4] could be an FIA, etc.

in reply to: ↑ 6   Changed 5 years ago by coke

Replying to whiteknight:

as a general note, not even entirely related to this ticket, if we are parsing ['foo','bar','baz'] as an FSA, I think it might be a good opportunity to consider using similar syntax to specify multiple types of PMC aggregate literals also. So [1,2,3,4] could be an FIA, etc.

If we're going down that route, what about [1,'2',3.0], etc.

  Changed 3 years ago by jkeenan

My naive impression, when reviewing this ticket which has gone untouched in 19 months, is that we're not going to make any changes in this functionality in the near- to medium-term future.

Can we close the ticket?

Thank you very much.

kid51

  Changed 3 years ago by bacek

Hello.

I still want to deprecate current Keys. This is decision for The Architect.

-- Bacek

  Changed 3 years ago by dukeleto

24% of the vtables in src/extend_vtable.c are key-related, as a data point.

Note: See TracTickets for help on using tickets.