From: Stefanescu, Mugur (Mugur.Stefanescu@BroadVision.com)
Date: Fri Dec 29 2000 - 23:06:15 EST
Dana,
Happy New Year, A Bonne Annee, La Multi Ani!
I think that we are saying similar things. In my understanding, casting
refers to a modification of the type and some widening/narrowing of data.
Now, it seems that TREAT AS is used for type casting only. If it can be used
for both up- and down-casting, it is indeed similar to type casting in Java
for a reference type, also roughly similar to dynamic_cast in C++.
CAST AS, however, seems to be used for data conversion. BTW, in Java, the
expression
foo.toString()
does not provide any casting, but simple data conversion. It is a simple
function/method accesible by being available in a superclass. For scalar
types (aka primitive types in Java), Java cannot use the same mechanism
since primitive types are not objects; so, one has to use class functions or
widening or narrowing cast operators, which indeed use internal conversion
functions, but it is simply a convenience. Note that data conversion has
copy semantics.
That is why it seems to me that CAST AS type(arg) does not provide more
value than just type(arg).
So, my question again is why can't we use only one syntax for casting (just
like in Java)? For instance the following are alternate syntaxes:
- IF $p INSTANCEOF duck THEN quack((duck)$a) -- as in Java and C
- IF $p INSTANCEOF duck THEN quack(CAST $a AS duck)
- IF $p INSTANCEOF duck THEN quack(TREAT $a AS duck)
- x + (string) y
- x + (CAST y AS string)
Of course, that implies that we provide a list of conversion functions
between built-in types as you said.
Am I making any oversimplification?
Mugur
-----Original Message-----
From: Dana Florescu
To: Stefanescu, Mugur; 'Don Chamberlin'
Cc: jwrobie@mindspring.com; Dana Florescu; simeon@research.bell-labs.com
Sent: 12/29/00 2:02 PM
Subject: RE: XQuery grammars
Mugur,
Let's look at Java and the way they do treat cast operators.
If x is of type Object you can either say:
(String) x
or
x.toString()
The first case is identical with our TREAT AS operator. Any type
can be used, independently whether it is a simple or complex type.
The second case is similar with our CAST AS.
For the second case Java provides a set of built-in function that
know how to convert simple Java types to other simple Java types
(strings to integers and so on). But this is limited to the simple built
in
types.
If an application wants to add a used defined function that know how to
convert
a salmon into a mammal, that's possible. In this case the conversion
happens
by traditionally invoking this function on a given salmon.
Maybe this is what should we do too:
-provide a set of conversion functions between simple XML Schema types
(12
times 12)
- use the extensibility mechanism to deal with the other conversions.
Does this make any sense?
Dana
-----Original Message-----
From: Stefanescu, Mugur [mailto:Mugur.Stefanescu@BroadVision.com]
Sent: Wednesday, December 27, 2000 10:42 AM
To: 'Don Chamberlin'
Cc: jwrobie@mindspring.com; danaf@crossgain.com;
simeon@research.bell-labs.com; Stefanescu, Mugur
Subject: RE: XQuery grammars
Don, thanks, for the explanation.
I still have some issues.
It seems that TREAT AS is somewhat similar to dynamic_cast in C++.
dynamic_cast does let you perform safe down-casting (using runtime type
information), but also up-casting (in which case is the same as
static_cast). Dynamic_cast (in C++) does not do any conversion, it just
makes sure that the whole object is there (for instance it may have been
upcasted before), but again it can go both ways. I do not see any
reasons
why TREAT AS should not do the same, that is call a function which takes
an
animal type: leash(TREAT AS animal($myfrog))
So, in my mind, type casting would use one operator which would be
translated into the algebra static or dynamic casting based on the
relative
generality or the arguments (target type and typeof(expression)). Am I
making an over-simplification?
Now, about CAST AS. This performs actual data conversion. I am trying to
understand how this would work. I'd like to make a distinction between
scalar types (XML datatypes) and non-scalar, and within scalar between
built-ins and user-defined.
I imagine that the supporting system (XQuery compiler + the supporting
library) will provide the conversion routines between built-in
datatypes;
for user defined datatypes, the user needs to provide conversion
routines
somehow.
How will these functions perform the conversion? Using copy or reference
semantics?
I.e., will they create new nodes or modify data in place?
Now, my guess is that conversion functions (system or user provided) 2
Date: Thu, 23 Nov 2000 14:55:44 -0600
Subject: [b-greek] Re: BDAG
From: "Steven R. Lo Vullo" <doulos@chorus.net>
To: Biblical Greek <b-greek@franklin.oit.unc.edu>
Message-ID:
<LYRIS-329-93645-2000.11.23-15.55.44--cwconrad#artsci.wustl.edu@franklin.oit.unc.edu>
In-Reply-To:
<LYRIS-121698-93615-2000.11.23-10.32.20--doulos#chorus.net@franklin.oit.unc.edu>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
List-Unsubscribe: <mailto:leave-b-greek-329W@franklin.oit.unc.edu>
Reply-To: "Steven R. Lo Vullo" <doulos@chorus.net>
On 11/23/00 9:40 AM, Steven Craig Miller wrote:
> My impression was that the biggest difference between
> the second (BAGD) and third editions (BDAG) is that BDAG is supposed to g=
et
> away from merely presenting English glosses for Greek words and in its
> place present "definitions" for Greek words, based on modern semantics. T=
he
> impression given (by Danker) was that this will revolutionize NT Greek
> lexicography.
It is interesting that Danker believes that this will "revolutionize" NT
Greek lexicography, since this approach has already been taken by others. I=
n
fact, one of the more significant criticisms of BAGD by Louw & Nida is
dependence on glosses. In the introduction to their _Greek-English Lexicon
of the New Testament Based on Semantic Domains_ (Johannes P. Louw and Eugen=
e
A. Nida, Editors Copyright =A9 1988, 1989 by the United Bible Societies, New
York, NY 10023 Second EditionFrom ???@??? Fri May 04 09:23:12 2001
Status: U
Return-Path: <bounce-b-greek-327@franklin.oit.unc.edu>
Received: from franklin.oit.unc.edu ([152.2.22.59])
by pickering.mail.mindspring.net (Earthlink Mail Service) with SMTP id tf3poc.9ja.37kbi14
for <jwrobie@mindspring.com>; Thu, 3 May 2001 19:17:27 -0400 (EDT)
X-Mailer: Lyris Web Interface
Date: Thu, 3 May 2001 17:16:15 -0400
Subject: [b-greek] Why MOICOS?
To: Biblical Greek <b-greek@franklin.oit.unc.edu>
From: "William Hale Boyd" <wmhboyd@aol.com>
List-Unsubscribe: <mailto:leave-b-greek-327Q@franklin.oit.unc.edu>
Reply-To: "William Hale Boyd" <wmhboyd@aol.com>
Message-Id: <LYRIS-327-38609-2001.05.03-19.17.29--jwrobie#mindspring.com@franklin.oit.unc.edu>
I have limited sources, but those I do have (Thayers, Vines & such like)
tell me that MOICOS is intercourse with another man's wife. Why then did
Jesus say, "Whoever marries a divorced woman MOICATAI?" If she is
divorced, then how is she another man's wife? and if she is NOT another
man's wife, then how is this MOICOS? So far my conclusion is that the
sources I consulted have not recgonized the use Jesus made of the word
"MOICOS" in Matthew 5:32 and Matthew 19:9. Are there lexicons (sources)
that do? Is MOICOS always intercourse with another's spouse?
Another question: (along the same line)
I heard a story about an old Greek that borded up his unwed daughter in a
house with a horse until she died because she was guilty of MOICOS. If
she was unwed, how was this MOICOS? Could the MOICOS have been the
violation of the trust (or legal obligation) she had to her father to
remain a virgin until until her marriage? Does someone know the source
for this story?
Thanks,
William Boyd
Little Rock
---
B-Greek home page: http://metalab.unc.edu/bgreek
You are currently subscribed to b-greek as: [jwrobie@mindspring.com]
To unsubscribe, forward this message to leave-b-greek-327Q@franklin.oit.unc.edu
To subscribe, send a message to subscribe-b-greek@franklin.oit.unc.edu
This archive was generated by hypermail 2.1.4 : Sat Apr 20 2002 - 15:36:56 EDT