1. about complex data type
reading datetime.e I just got an idea that is not specific to it.
looking at this type definition
global type datetime(object o)
return sequence(o) and length(o) = 6
and integer(o[DT_YEAR]) and integer(o[DT_MONTH]) and integer(o[DT_DAY])
and integer(o[DT_HOUR]) and integer(o[DT_MINUTE]) and atom(o[DT_SECOND])
end type
one see that it take a large boolean expression to check the nature of complex
data type like this one. My idea is why not use a tag to identify complex data
type. the first element of the sequence being the tag. In this exemple every
datetime object would be like: {"DATETIME",...}
and the type would be.
global datetime(object o)
return sequence(o) and equal(o[1],"DATETIME")
end type
an idea that can be applied to any complex data type.
the TAG could be a GUID to play safer.
and any library that define such a complex data type would have a global
function to create a valid sequence with the tag.
for exemple in datetime.e now() would be modified as such
global function now()
return {"DATETIME"}& from_date(date())
end function
and all orther functions according to such
Just my 2cent idea.
Jacques d.
2. Re: about complex data type
jacques desch�nes wrote:
> }}}
<eucode>
> global datetime(object o)
> return sequence(o) and equal(o[1],"DATETIME")
> end type
> </eucode>
{{{
>
> an idea that can be applied to any complex data type.
Is it faster? It needs a string comparison.
And it uses much more bytes to store.
Current data structure:
sequence = 16 bytes
5 integer = 20 bytes
1 atom = 12 bytes
Total = 48 bytes
Using the tag has this additional:
1 string sequence = 16 bytes
1 sequence pointer = 4 bytes
integers "DATETIME" = 32 bytes
Total 48+52 = 100 bytes
So it is more than twice the memory needed.
3. Re: about complex data type
jacques deschênes wrote:
>
> }}}
<eucode>
> global datetime(object o)
> return sequence(o) and equal(o[1],"DATETIME")
> end type
> </eucode>
{{{
In direct regards to the datetime type, it may also be nice to further the
existing type check to include checks for month >= 1 and <= 12, day >= 1 and day
<= 31, etc... So, each element would need to be checked anyway.
Right now it does not do those checks, but if necessary, it could in it's
current form.
--
Jeremy Cowgar
http://jeremy.cowgar.com
4. Re: about complex data type
jacques deschênes wrote:
> reading datetime.e I just got an idea that is not specific to it.
>
> looking at this type definition
> }}}
<eucode>
> global type datetime(object o)
> return sequence(o) and length(o) = 6
> and integer(o[DT_YEAR]) and integer(o[DT_MONTH]) and integer(o[DT_DAY])
> and integer(o[DT_HOUR]) and integer(o[DT_MINUTE]) and atom(o[DT_SECOND])
> end type
> </eucode>
{{{
>
> one see that it take a large boolean expression to check the nature of complex
> data type like this one. My idea is why not use a tag to identify complex data
> type. the first element of the sequence being the tag. In this exemple every
> datetime object would be like: {"DATETIME",...}
> and the type would be.
>
> }}}
<eucode>
> global datetime(object o)
> return sequence(o) and equal(o[1],"DATETIME")
> end type
> </eucode>
{{{
But you're only checking to see if it "says" that it's the correct type.
What if some buggy code dropped an element somewhere, or changed something
into a sequence? You'd never know, and would have removed the usefulness
of type checking, which is really a development tool, not for runtime
support. If you're concerned about speed, just turn off type checking
Matt
5. Re: about complex data type
Jeremy Cowgar wrote:
>
> In direct regards to the datetime type, it may also be nice to further the
> existing
> type check to include checks for month >= 1 and <= 12, day >= 1 and day
> <= 31, etc... So, each element would need to be checked anyway.
>
> Right now it does not do those checks, but if necessary, it could in it's
> current form.
Yes, it should validate its data. It would be useful for checking for things
like valid user input with explicit calls, rather than implicit type
checking.
Matt
6. Re: about complex data type
So for you 'type' is there only as an assert() to be used only at devellopment
phase. For me 'type' is more like reflection it tell us at runtime the nature of
a data object. As data type are dynamics in euphoria it is usefull to have
reflection. Obviously the TAG doesn't garanty that the data structure is OK and
it is not its purpose. datetime is a relativly simple data structure, one could
image more complex data structure than that. Which ones it will not be practical
to check every element for correctness but a tag will reflect the nature of the
object.
Anyway its an idea I will eventually use in my personnal projects.
Jacques
Matt Lewis wrote:
>
> jacques deschênes wrote:
>
> > reading datetime.e I just got an idea that is not specific to it.
> >
> > looking at this type definition
> > }}}
<eucode>
> > global type datetime(object o)
> > return sequence(o) and length(o) = 6
> > and integer(o[DT_YEAR]) and integer(o[DT_MONTH]) and
> > integer(o[DT_DAY])
> > and integer(o[DT_HOUR]) and integer(o[DT_MINUTE]) and
> > atom(o[DT_SECOND])
> > end type
> > </eucode>
{{{
> >
> > one see that it take a large boolean expression to check the nature of
> > complex
> > data type like this one. My idea is why not use a tag to identify complex
> > data
> > type. the first element of the sequence being the tag. In this exemple every
> > datetime object would be like: {"DATETIME",...}
> > and the type would be.
> >
> > }}}
<eucode>
> > global datetime(object o)
> > return sequence(o) and equal(o[1],"DATETIME")
> > end type
> > </eucode>
{{{
>
> But you're only checking to see if it "says" that it's the correct type.
> What if some buggy code dropped an element somewhere, or changed something
> into a sequence? You'd never know, and would have removed the usefulness
> of type checking, which is really a development tool, not for runtime
> support. If you're concerned about speed, just turn off type checking
>
> Matt
7. Re: about complex data type
jacques deschênes wrote:
>
> So for you 'type' is there only as an assert() to be used only at devellopment
> phase. For me 'type' is more like reflection it tell us at runtime the nature
> of a data object. As data type are dynamics in euphoria it is usefull to have
> reflection. Obviously the TAG doesn't garanty that the data structure is OK
> and it is not its purpose. datetime is a relativly simple data structure, one
> could image more complex data structure than that. Which ones it will not be
> practical to check every element for correctness but a tag will reflect the
> nature of the object.
>
> Anyway its an idea I will eventually use in my personnal projects.
The tag idea might make sense in some cases, because you could avoid doing
detailed checking if it's something else. I guess it depends upon how
you want to use the type check system, and what you expect the type
checking to do for you.
Matt
