Dan Sugalski:
# 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)
I think autochomp is a value property, not a variable property.
# 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'd suggest that key=name of property, value=PMC representing the
property (see below).
# >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.
I'd expect it to allocate 1000 strings, but leave the Shift-JIS to the
encoding property and the string sizing to the max_len property.
# >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.
I'd suggest we have Property PMCs and a vtable method
apply_property(INTERP, prop_pmc, target_pmc). init() would look through
a list of Properties passed to it, handle the ones it knew how, and call
apply_property on the ones it didn't know how to handle.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
