On 22 July 2013 11:53, Dan Douglas <orm...@gmail.com> wrote:
> On Monday, July 22, 2013 11:08:35 AM Irek Szczesniak wrote:
>> On Mon, Jul 22, 2013 at 11:00 AM, Dan Douglas <orm...@gmail.com> wrote:
>> > In this type, I can't think of any way to refer to "obj" from within
>> > "x.get".
>> > _ should point to "obj" in this context, not "obj.x".
>> >
>> > #!/usr/bin/env ksh
>> >
>> > typeset -T Type=(
>> > typeset -h 'This will be a property.' x
>> > integer -h 'This will be the backing field for x.' y=5
>> >
>> > function x.get {
>> > # Huge problem here because _ refers to x,
>> > # we can't access anything.
>> > ((.sh.value = ++_.y))
>>
>> This can't work. .sh.value is identical to _
>>
>> Think about ksh93 types as compound variables with predefined
>> discipline functions. In your example you're trying to assign the
>> value of ++_.y to the value of a compound variable - which obviously
>> cannot work.
>>
>> Irek
>
> I don't know, it doesn't make sense to me for disciplines within types that
> hook the fields of the type. I think _ should be different here than for a
> bare discipline defined in the global scope. Those don't have to care about
> which instance they are a part of.
>
> The only workarounds I can think of are nasty, like:
> nameref this=${.sh.name%.*}; .sh.value=${this.y};
Oh, I got it. What we need is a way to access the parent of a
variable, like cd .. accesses the parent directory. _... obviously
won't work.
What about _._ to access the parent in both types and compound variable trees?
For example:
compound c1=( compound c2=( integer i=5 ) )
nameref n1=c1.c2.i
nameref nc2=i._ # accesses c2 though i
nameref nc1=i._._ # accesses c1 through i
Ced
--
Cedric Blancher <cedric.blanc...@gmail.com>
Institute Pasteur
_______________________________________________
ast-users mailing list
ast-users@lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-users
