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.
----- Original Message -----
From: "Carl Sassenrath" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 27, 2001 12:58 PM
Subject: [REBOL] Re: Use of 'context
> 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
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Brett Handley
> > Sent: Thursday, April 26, 2001 5:50 PM
> > To: [EMAIL PROTECTED]
> > Subject: [REBOL] Re: Use of 'context
> >
> >
> > 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.
> >
> >
> > ----- Original Message -----
> > From: "Carl Sassenrath" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Friday, April 27, 2001 2:15 AM
> > Subject: [REBOL] Re: Use of 'context
> >
> >
> > > 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
> > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > > > Brett Handley
> > > > Sent: Thursday, April 26, 2001 2:54 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: [REBOL] Re: Use of 'context
> > > >
> > > >
> > > > 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.
> > > >
> > > > ----- Original Message -----
> > > > From: "Brett Handley" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Thursday, April 12, 2001 9:31 PM
> > > > Subject: [REBOL] Re: Use of 'context
> > > >
> > > >
> > > > > > 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.
> > > > >
> > > > > --
> > > > > To unsubscribe from this list, please send an email to
> > > > > [EMAIL PROTECTED] with "unsubscribe" in the
> > > > > subject, without the quotes.
> > > > >
> > > >
> > > > --
> > > > To unsubscribe from this list, please send an email to
> > > > [EMAIL PROTECTED] with "unsubscribe" in the
> > > > subject, without the quotes.
> > > >
> > > >
> > > --
> > > To unsubscribe from this list, please send an email to
> > > [EMAIL PROTECTED] with "unsubscribe" in the
> > > subject, without the quotes.
> > >
> >
> > --
> > To unsubscribe from this list, please send an email to
> > [EMAIL PROTECTED] with "unsubscribe" in the
> > subject, without the quotes.
> >
> >
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
>
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
