[xinf] DOM Events?

[hank williams]

If you use enums, then you cant communicate with the outside world. You
couldnt optionally add this to an existing enum based model. Though you
could have two totally separate system, thought that seems clunky to me as
well.

As I said in my last post, I actually think my system would not impose any
burden on the programmer if done right because they wouldnt need to see it.

On additional thought is if enums could be strings instead of numbers then
we *could* have the best of both worlds! This would require a change or
enhancement to haxe, but it might just solve the problem if haxe could allow
a string to define a type within the compiler. Then we wouldnt need to infer
a compled type from its field types, we could absolutely determine its type
based perhaps in part by the fields but in conjunction with a string.

Hank

On 6/23/06, Lee McColl-Sylvester <lee.mccoll at lyons-group.co.uk> wrote:
>
>  Sounds to me like two options are going to be necessary.  Perhaps a loose
> Xml layer that will need to be constucted by hand (or force exported) and
> linked in order to provide cross platform integration, while standard events
> usage would have no such requirement, so no Xml file.
>
>
>
> Lee
>
>
>
>
>
>
>  ------------------------------
>
> *From:* xinf-bounces at xinf.org [mailto:xinf-bounces at xinf.org] *On Behalf Of
> *hank williams
> *Sent:* 23 June 2006 16:44
>
> *To:* xinf is not flash
> *Subject:* Re: [xinf] DOM Events?
>
>
>
> I agree, it is a little clunky. But I think it solves the problem in a way
> that satisfies all the requirements. In actuality, the user would never come
> across this directory unless they were doing cross platform stuff.
> Otherwise, haXe could do all of this without the user even knowing. Even the
> directory would not have to be defined on the command line. It could be a
> default unless changed kind of thing. But yes, if you need to do the kind of
> thing that Dan and I are doing i.e. cross platforms etc., there is an
> extra, clunky step. But for me it would be worth it. For everyone else, it
> could be seamless.
>
> Hank
>
> On 6/23/06, *Lee McColl-Sylvester* <lee.mccoll at lyons-group.co.uk> wrote:
>
> That's a little clunky, though, don't you think?  Maybe an XML object that
> you can include as a resource, but even then it's clunky
>
>
>
> Lee
>
>
>
>
>
>
>  ------------------------------
>
> *From:* xinf-bounces at xinf.org [mailto: xinf-bounces at xinf.org] *On Behalf
> Of *hank williams
> *Sent:* 23 June 2006 16:34
>
>
> *To:* xinf is not flash
> *Subject:* Re: [xinf] DOM Events?
>
>
>
> Ok, so I am going to suggest what I said before was my idea as to how to
> resolve this issue. Remember Nicolas you promised to listen :). It would
> require a change to haxe, but it could solve the problem.
>
> Basically, when a file or project is compiled, an "events identifier"
> directory is identified on the command line. The file contains a platform
> neutral (XML) description which includes the unique name of all the events
> published and all the events subscribed to. Each XML event descriptor has as
> a field a name which helps to semantically disambiguate. Each event
> descriptor also has all the fields and field types for the data associated
> with the event.
>
> So within the events identifier directory there are two folders, one for
> published events, and one for subscribed to events. The compiler generates
> an error if any event in the subscribers folder has a name that matches a
> name in the publishers folder but where the event field types do not match.
>
> This would allow for Nicloas's type checking at compilation time. It would
> also allow cross platform communications by allowing other languages to see
> what events are available for a given module, and how to communicate with
> it. No specialized code would be required for anyone to play here. Of course
> your C code isnt going to get the benefit of the type checking without a
> preprocessor, but even this is possible.
>
> Of course I havent read the full w3c events spec, but I bet I am just
> suggesting something that in some form or another they have already thought
> of.
>
> Regards
> Hank
>
> On 6/23/06, *daniel fischer* <dan at f3c.com> wrote:
>
> "hank williams" <hank777 at gmail.com > (on Fri, 23 Jun 2006 10:04:59 -0400):
>
>   > I need a way to communicate semantic
>   > intent of the event. Your system doesnt do that
>
> seems you are right here. semantics in nicolas' proposal are implied by
> the dispatcher variable "name". i'd prefer explicit "event types" ("what
> happened?") too. i cannot think of anythin better than string, although
> using strings also poses problems...
>
> deadlocked?
>
> -dan
>
> --
> http://0xDF.com/
> http://iterative.org/
>
> --
> xinf is not flash
> http://xinf.org/
>
>
>
>
>
> --
> xinf is not flash
> http://xinf.org/
>
>
>
>
> --
> xinf is not flash
> http://xinf.org/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://xinf.org/pipermail/xinf/attachments/20060623/3fd76f1a/attachment.html