I did find another useful idiom for accessing object instances that seems close to what I wanted to do in the beginning.
3 : 'field__y' can be applied to an object, with the proper ranks, a list of objects. (3 : 'field__y') <'2' would return the result of field__ from instance 2. so a filter action like this should work: 3: 'y #~ 0 < field__y' > remember that J supports using boxed numbers to select from arrays I'm not aware of that, or don't know what you mean. >Conceptually speaking, the justification for including objects and >classes in J was to allow independent programmers to build subsystems >which can be used together or which can be consumed by other coders. Objects are useful for tracking resources (sockets or trying to manage processes across cores or network nodes), and convenience of contextual control flags (semi-global variables that are global to a context of related fields). Advanced control structures that track information across calls or multiple functions. I completely agree that the power of J lies with keeping core data as arrays. Even flags related to that data are probably best kept as parallel arrays or table elements. ________________________________ From: Raul Miller <[email protected]> To: Programming forum <[email protected]> Sent: Sunday, September 1, 2013 6:05:57 PM Subject: Re: [Jprogramming] OOP programming - building method/field access On Sun, Sep 1, 2013 at 12:08 AM, Pascal Jasmin <[email protected]> wrote: > 'field' of < '2' NB. Object instances are boxed string of a number afaik >(why string?) > field_2_ This increases the chance of detecting mis-use of an instance reference: they are not valid indices into an array (remember that J supports using boxed numbers to select from arrays). > Is all of this a bad idea? Worth avoiding objects whenever possible > including the "hack" at the top of this post that creates and destroys top > level verbs? > Are there other approaches that make managing lists of objects easy/possible? Conceptually speaking, the justification for including objects and classes in J was to allow independent programmers to build subsystems which can be used together or which can be consumed by other coders. Other uses can be academically interesting, and useful for exploring ideas, but arrays are a lower-level concept than objects. In other words, for efficient machine use you should probably put arrays inside objects instead of the other way around. However, if efficiency is not an issue for you, there's no problem with having arrays of objects in production code. Is this point of view relevant to you? Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
