[RFC] Deprecate Keys at all.

[bacek]

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

[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

[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

[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']
  

[allison]

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

[bacek]

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

[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.

[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.

[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

[bacek]

Hello.

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

-- Bacek

[dukeleto]

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