in reply to Re: reference to an undefined key
in thread reference to an undefined key

You can't access attributes of an object before the object is created.
Yes, I know why my example won't work... but I am juz looking for if any work around to declare and define my object's properties in the style alike what I hope can happen.
you can create the object up-front, then access all of its attributes before returning it...
That's what I know I can deal with it so far, as shown in my original post ..so sad! =(

Replies are listed 'Best First'.
Re^3: reference to an undefined key
by AnomalousMonk (Archbishop) on Oct 10, 2015 at 17:33 UTC
    ... I know why my example won't work... but I am juz looking for if any work around to declare and define my object's properties in the style alike what I hope can happen.

    The Monastery may harbor certain subtle and puissant monks who possess the dark art of accessing an object before that object is completely defined, but their ways should not be yours if you seek the Way of Clarity!

    If you wish "to state the logic of the properties in clear", I don't see why, combining the approaches of golux and stevieb with my own personal preferences, an approach like

    sub new { my $class = shift; my ($uid, $root, $app) = @_; my $obj = bless {} => $class; $obj->{Root} = $root; $obj->{UserDir} = "$obj->{Root}/Usr/$uid/"; $obj->{UserAppData} = "$obj->{UserDir}$app"; return $obj; }
    or maybe
    sub new { my $class = shift; my ($uid, $root, $app) = @_; return bless { Root => $root, UserDir => "$root/Usr/$uid/", UserAppData => "$root/Usr/$uid/$app", } => $class; }
    (both tested) would not be sufficiently clear. (Note the trailing / path separator is not needed on the  $root path specification.) Why be sad? Bask in the light of the Clear Path!

    Update: Just to be sure:


    Give a man a fish:  <%-{-{-{-<

Re^3: reference to an undefined key
by stevieb (Canon) on Oct 10, 2015 at 19:55 UTC

    I agree completely with AnomalousMonk's post here: Re^3: reference to an undefined key. There *are* ways to do what you want (and we could definitely point them out), but it would involve using magic that isn't advised for standard use cases.

    Trying things out is one thing, but for code you're going to use, it's best to use idiomatic Perl that you, and anyone in the future can read easily at a glance six months after it is written.

    If you want to force your will upon a data structure creation, you'll want to look at symobolic references, and understand the symbol table. There's a decent intro here on PM: Of Symbol Tables and Globs.

    Again though, using magic to do things in a non-conventional way often leads to bugs that are "far away" or "at a distance" from the code that uses said magic, while leaving code that yourself, or others might not be able to comprehend in the future (even after a lot of review and tracing).

    With all those warnings stated, we don't learn how to force perl to do things unconventionally without pushing our limits of what we know.