At 2:51 PM +0000 3/13/02, Tim Bunce wrote:
>On Wed, Mar 13, 2002 at 09:03:13AM -0500, Dan Sugalski wrote:
>> I like the fact that we're adding an arg to init to decide how big to
>> make the resulting PMC. It got me to thinking, though. Perhaps we'd
>> be even better served if we passed in something a bit more complex.
>>
>> We are, after all, likely to get something like this at the perl level:
>>
>> my Str @foo is dim(10, 10, 10), encoding "Shift-JIS",
>> max_len(40), autochomp;
>>
>> or something sort of like that. We'd really like to pass in the dim,
>> encoding, max_len, and autochomp to the init method, so it can init
>> things properly.
>
>You're presuming that a single 'init' *should* look after all that.
More I'm presuming a single init should be able to see all the
properties that will potentially be placed on the variable. In the
case above, all the properties are variable properties, assuming
they're mandatory declarations about the contents permissible in the
array. (In this case a 10x10x10 fixed size string array that only
holds Shift-JIS characters, strings of no more than 40 characters
long, that are automatically chomped when put into the array)
It's certainly true that value properties should either be ignored by
the init method, or never passed to the init method in the first
place. The question then is whether we can tell which properties are
value properties and which are variable properties at compile time. I
expect it'll be mixed--some we will, some we won't, in which case we
pass in the variable and indeterminate ones and let the init method
figure out which ones it likes and which it doesn't.
>That doesn't seem very practical or extensible etc.
Depends on how we pass them in. A set of key/value pairs would make
sense, and if the keys could potentially be strings for attributes
whose properties are unknown at compile time it's reasonably
extensible.
>I recall Larry saying something (roughly) along the lines that
>attributes, like the above, could be thought of, and possibly
>implemented as, method/function calls on the variable/value.
>That seems like a much more extensible approach.
Perhaps. We could certainly init the variable, then do a bunch of
property assigning method calls, but that's potentially inefficient.
Especially in the case of properties that define or restrict
sizes--we may find ourselves creating and then recreating a PMC
several times before the initialization is complete.
In the above case, if we pass in all the properties at init time, the
init method can potentially statically allocate 1000 pre-sized
Shift-JIS strings and be done with it.
>Perhaps some kind of variable/value init framework is needed
>and maybe an 'init' will play a part in that. But if so, I think
>the init probably shouldn't have knowledge of what encoding, max_len,
>and autochomp *mean*, it should just make the method/function calls.
>There's obviously a whole bunch of potential ordering issues.
But the vtable code for the PMC is where the various attributes are
potentially given meaning. Init ought to have that information passed
in so that it can interpret the information if its appropriate. Every
init for every array type may not know about those properties--heck
none of the inits for any array type might. But they potentially
could, and it doesn't seem to make sense to restrict that possibility.
Mandating that the init method must make appropriate property setting
calls for properties unknown to it would be a reasonable thing. That
way init can handle some things, and the rest can be punted on, but
we don't need special case code anywhere but in init, where it's
appropriate.
>p.s. And for some reason I'm reminded of Larry's reminder not to
>confuse variables with values.
I'm reminded of that on a fairly regular basis. It definitely
complicates things somewhat.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
