Re: Comments on ORAC
Pete Lomax wrote:
>
> Mike wrote:
> >
> > Orac (as a pp) is a stepping stone to a greater goal.
> OK, good to know.
> >
> > > 2) Conditional compilation:
> > This example would fail in Orac.. was that your intention? I couldn't work
> > it out, sorry 
> My bad, I really meant to say conditional compilation is only useful for fixed
> literal constants, such as "constant ASSERT=1" then "if ASSERT then", and/or
> stripping out assert() and trace() statements, but not conditional includes
> imho. In the docs you listed:
> * OS version string/{type,major,minor}
> * Current video mode
> * Screen size (text-mode)/resolution (graph mode).
> * Current printer flags: technology (laser, inkjet, dot-matrix), PCL, etc..
> * dpi values for screen and printer
> * keyboard layout string
> * Locale string or id
> * Unicode support (current CP should be enough)
> Now, if *ANY* of those were applied in the next public release of Edita, or
> wxEuphoria, not too many people would likely be happy.
> In other words I am not inspired with confidence by a system that proposes to
> do such things, and given the choice I would disable such permanently.
> >
Really?
Granted, the video config isn't the best example; availability of such or such
video mode on the host machine, or hysical cpabilities of this or that device, is
probably more useful.
You can easily unerstand that some libraries won't be the same in an ANSI or
Unicode context, or according to the command language a printer understands, etc.
Rather than having monolithic libraries that need to handle it all, it is much
cleaner to have one librry per relevant configuration and include it
conditionally. Sounds like implementing virtual methods? Yes, it makes much
simpler to maintain and extend.
> > Oh. BTW, what does Backward Compatibility mean? I never really knew what
> > that was..
> > .. does someone have a dictionary..?
> I think it means suitable for retarded people 
>
Agreed.
> > > Indirect routine calls:
> > If we could do: xDeleteObject(hWnd) well, that would be just great. If
> > someone
> > could please tell me how to detect the difference between an integer that is
> > the result
> > of a dll link and an integer that is a routine_id
>
> CChris might know whether it is possible to merge the routine_id and c_func
> tables in the backend or not.
>
> Alternatively, why not just add say #30000000 to define_c_proc results,
> #20000000
> to define_c_func, and #10000000 to routine_ids of procedures?
>
> Hence if and_bits(n,#20000000) then it is a C routine else an Eu one,
> and if and_bits(n,#10000000) then it is a procedure else a function,
> and mask these things with #0FFFFFFF before use.
>
Merging is probably doable - there are always some pitfalls in merging things
that are not processed in exactly the same way. I'd suggest rather using the
lower 2 bits to stand for func vs proc and routine_id vs defined_c_routine. Basic
indexes would increment by 4, and getting the table offset would be done by a
fast >>2.
Ability to tell these characteristics from simple inspection of the id would
have greatly simplified my http://oedoc.free.fr/Fichiers/ESL/function.zip
package.
CChris
> Regards,
> Pete
|
Not Categorized, Please Help
|
|
