Use of 'context
[1/9] from: coussement:c:itc:mil:be at: 12-Apr-2001 12:56
Hi list: I recently discover the 'context word, but I do not see what functionality it adds compared to the creation of an object :
REBOL/Command 126.96.36.199.1 19-Sep-2000 Copyright 2000 REBOL Technologies. All rights reserved.
>> help context
USAGE: CONTEXT blk DESCRIPTION: Defines an underived object. CONTEXT is a function value. ARGUMENTS: blk -- Object variables and values. (Type: block)
>> c: context [val: make integer! 999] >> probe c
make object! [ val: 999 ]
>> o: make object! [val: make integer! 999]
>> probe o
make object! [ val: 999 ]
== 999 </snip> What the purpose of this? What does RT means by "underived" (perhaps un-inherited ) ? Regards, chr==
[2/9] from: brett::codeconscious::com at: 12-Apr-2001 21:31
> I recently discover the 'context word, but I do not see what functionality > it adds compared to the creation of an object :
Currently doesn't add any functionality, but does add readability.
>> source context
context: func [ "Defines a unique (underived) object." blk [block!] "Object variables and values." ][ make object! blk ]
>What does RT means by "underived" (perhaps > "un-inherited") ?
I suspect just that it is a new object as opposed to one created like the following first-object: context [name: "first"] derived-object: make first-object  Brett.
[3/9] from: coussement:c:itc:mil:be at: 12-Apr-2001 13:42
> -----Original Message----- > From: Brett Handley [SMTP:[brett--codeconscious--com]]
<<quoted lines omitted: 19>>> derived-object: make first-object  > Brett.
[ I don't get the point of RT, but I think you're right. Thanks for answering. CU chr== ]
[4/9] from: agem:crosswinds at: 12-Apr-2001 17:40
>Hi list: > >I recently discover the 'context word, but I do not see what
>it adds compared to the creation of an object : >
no adds, a shortcut. derived means [make from-this! ] underived means from empty-object
[5/9] from: brett:codeconscious at: 26-Apr-2001 19:54
Gee it took a while for me to realise... context takes a block! as an argument - which constrains what context can do- it can only take a block as a spec. compare this with the following which can use an object as a spec template-object: context [ name: does [print "template"] template-function: does [print "template func"] ] spec-object: context [ name: does [print "spec"] special-function: does [print "special"] ] specialised-object: make template-object spec-object so if you do probe specialised-object you get make object! [ name: func [print "spec"] template-function: func [print "template func"] special-function: func [print "special"] ] Brett.
[6/9] from: carl:rebol at: 26-Apr-2001 9:15
Brett, What else would you want it to take? If you want to merge two objects, as you have done, then you use MAKE, not CONTEXT. Your example is correct. CONTEXT is simply a shortcut mezzanine, similar to DOES, HAS, etc. -Carl
[7/9] from: brett:codeconscious at: 27-Apr-2001 10:49
Carl, In my message I had no desire to have it take anything else. When I said constrains I was viewing it positively like a database constraint increases the integrity of a database. Sorry for the ambiguous language. It was only now that I realised the earlier discussion on this thread had no highlighting of the new "make object!" behaviour which was introduced in Core 2.5 - hence my message. But now that you have asked. I was musing last night on what the use of N x objects clumped together would be - even called it a name n-objects: SITUATION [obj1 obj2 obj3...] I imagined that if each of these source objects represented an encapsulated capability than the combined object might in effect be a melding of capabilities where overlapping fields become the glue of funtionality. Then I woke up and realised 1) Name clashes between non-glue bits is a pain. 2) N = 2 case is handled by make object object 3) I've just described the global context and modules make come down the track. Still it might be nice to have multiple "situations" - but I don't know. Back to musing. :) Brett.
[8/9] from: carl:rebol at: 26-Apr-2001 19:58
I've been thinking somewhat along similar lines, but for the purposes of name-value set functions. The data set operations (union, intercept, exclude) would be able to operate on such objects. -Carl
[9/9] from: brett:codeconscious at: 27-Apr-2001 14:58
I'm a little unsure of your actual intention. Union is effectively already implemented in "make object obj" (where the name is the key) so it makes sense that you are considering adding the other operations intersect and exclude. Alternatively, is it that you are considering the name+value pair as the key? Which could prove interesting to a person trying to read the definition of an object (ambiguous field names). Or I've lost the plot totally. So I'll stop there before I really embarass myself :) Sounds intriguing though. Brett.
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted