Those examples are two abstract. Can you come up with some actual verb members and data members of the objects? Such as
NB. ========================================================= coclass 'pacc' create=: 3 : 'bal=: y' destroy=: codestroy cocurrent 'base' acc=: conew&'pacc'"0 at=: 1 : '3 : ((m,''__y'');'':'';m,''__y >x'')"0' NB. ========================================================= ]a=. acc 100 +---+ |130| +---+ bal__a 100 destroy__a'' 1 ]lst=: acc i.10 +---+---+---+---+---+---+---+---+---+---+ |131|132|133|134|135|136|137|138|139|140| +---+---+---+---+---+---+---+---+---+---+ 'bal' at lst 0 1 2 3 4 5 6 7 8 9 a: 'destroy'at lst 1 1 1 1 1 1 1 1 1 1 --- Yuvaraj Athur Raghuvir <[EMAIL PROTECTED]> wrote: > Cross-posting taking Chris' suggestion.... > > On 10/4/06, Chris Burke <[EMAIL PROTECTED]> wrote: > > > > Yuvaraj Athur Raghuvir wrote: > > > I find the tacit programming style available in J fascinating. > > > > > > And I find that there is support for Object Oriented programming in J!! > > > > > > But I am not sure if Objects fit into the paradigm of J naturally. What > > are > > > objects as "parts of speech"? Would it be right to talk about objects > > as > > > "nouns"? Or, is "noun with behavior(verb)" a better definition? > > > > A good start for OOP in J is the lab, Object Oriented Programming. > > > > As Raul points out, objects are collections of names. The underlying > > idea is that of locales. > > > > Pretty well any significant application in J makes essential use of > > objects. The J IDE is an example - it is written in J and each ijx/ijs > > window is an instance of a session object. > > > > Incidentally, feel free to post questions like this to the programming > > forum. Chat is more for items that are off-topic to J. > > ---------------------------------------------------------------------- > > ---------- Forwarded message ---------- > From: Yuvaraj Athur Raghuvir <[EMAIL PROTECTED]> > Date: Oct 4, 2006 6:06 AM > Subject: Re: [Jchat] Objects & Tacit programming? > To: Chat forum <[EMAIL PROTECTED]> > > > Raul, you have used objects as a Locale - which is probably the standard > interpretation of object in J. And in this locale, you have added a verb > that is tacitly defined. Thats dove-tailing tacit into object programming. I > ment something where the two paradigms are at equal footing. Let me try with > lots of imagination and an example.... > > When I say "using tacit programming style with objects", I would first > define objects as an entity that encapsulates state and behavior. > > So, an object for me is a name for > a) a collection of nouns (=state) > b) a collection of verbs > > The important difference is that the object::verbs work on a domain that > includes the object::nouns if they modify the object::nouns. Else > object::verbs can have any domain. > > Now an example... (caution - more a thought experiment...my J syntax might > be wrong....please bear with me) > > coclass 'customer' > customer__setname NB. setname is a verb in customer > customer__getname NB. getname is a verb in customer > ... > > coclass 'product' > product__getid NB. getid is a verb in product > product__getprice NB. getprice is a verb in product > > Now, I want: > > order =: customer *buys* product NB. implicit/tacit definition of new > object as an interaction between two objects > > The operator "buys" should be able to define how the new object order is in > terms of nouns & verbs that is inferred from customer & product. > > This reflects the tacit programming style at the level of objects where I > understand tacit programming as follows: > a) no explicit naming of data (here data is implicit in the object) --> > anonymity criteria > b) there is a clear algebra defined between the objects --> like hook, fork, > combination rules etc > c) there can be 'trains' of objects like so: (again a thought experiment and > a representation more than precise statement) > ordermanagement =: (*maintain* product) (*maintain* customer) (order > =:customer *buys* product) (order *has* reports) > > Or, in general, any statement that can be made about tacit programming using > the constructs of J (verbs, adverbs, conjunction etc) should be valid when > used with objects > > I could also rephrase my question as: what would it take for tacit > programing paradigm, which to me is based on the algebra of mathematical > notations, to be promoted to "object algebra", which likewise is an > "algebra based on objects"? > > > > > On 10/4/06, Miller, Raul D <[EMAIL PROTECTED] > wrote: > > > > Yuvaraj Athur Raghuvir wrote: > > > But I am not sure if Objects fit into the paradigm of J naturally. > > > What are objects as "parts of speech"? Would it be right to talk > > > about objects as "nouns"? Or, is "noun with behavior(verb)" a > > > better definition? > > > > I'd classify these objects as a named collection of names. > > > > > Hmm...how did objects become part of J? > > > > I'm not an authority, but from my point of view they were > > included to help people build large projects, with > > relatively clean internal interfaces. > > > > > I am wondering what does it mean to extend the paradigm of > > > tacit programming to objects. > > > 1) Does tacit programming apply to objects in J as it stands? > > > > Sure, though mostly as a way of providing building blocks. > > > > Tacit programming works with names, but in tacit programming you > > are building up anonymous expressions and then [later] using > > these expressions as the definition for some names. > > > > > 2) If yes how is it done? > > > > Um... maybe like this? > > > > coclass 'example' > > mean=: +/ % # > > > > Conceptually, you might build up tacit expressions which > > also manipulate names, but I wouldn't want to do that just > > to be able to say that I had done so -- I'd want this to > > be a meaningful abstraction for dealing with a real issue. > > > > > 3) If no, where do both the paradigms - tacit programming > > > & object oriented programming - conflict? > > > > See above: object oriented programming centers around > > naming issues, and tacit programming centers around > > anonymous expressions. These can overlap, but do not > > always overlap. > > > > A somewhat related issue: when I work with tacit expressions, > > I like my expressions to be repeatable. This lets me test > > them easily. Objects often have internal state, which makes > > testing more cumbersome (tests need to be a bit more formal > > and explicit -- object tests for stateful objects generally > > don't fit easily inside an expression). > > > > -- > > 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 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
