in reply to Maintaining State with Runtime Traits

We were presenting the users with lists and they needed to select one or more items from those lists.

It seems to me that the appropriate place for my %is_selected; is inside the code that presents the list to the user and lets them select one or more items. And that code should know how to return the list of selected items (that code might be encapsulated in a class, depending).

The problem with free'ing the %is_selected is just one symptom of a poor solution that doesn't scale. Consider if you need to select more than one set of servers. You only have one is_selected() method per object. But if you present the user with the opportunity to select a subset twice, then by putting the information about what they selected in a more appropriate place, there is no problem if you need multiple subsets selected (and this information is deleted when you are done with it).

- tye        

Replies are listed 'Best First'.
Re^2: Maintaining State with Runtime Traits (where)
by Ovid (Cardinal) on Oct 11, 2006 at 06:01 UTC
    The problem with free'ing the %is_selected is just one symptom of a poor solution that doesn't scale.

    The problem with freeing that is a problem with adding traits to a language which doesn't natively support them. It has nothing to do with whether or not the concept is appropriate.

    As for the rest of what you typed, it might be a great way of looking at the problem but it's completely irrelevant to my specific coding problem. With runtime traits, my code is cleaner and easier to read. Solutions should be created to match actual problems faced, not "what if" scenarios -- unless those scenarios have a realistic chance of occurring. For the purposes of the code I was working on, it's been used for years and is quite stable. Your scenario is highly unlikely to apply.

    Cheers,
    Ovid

    New address of my CGI Course.

[reply]

In Section Meditations