Re: [MacPerl] Mac::Glue progress

[Chris Nandor <pudge@pobox.com>]

At 19.23 -0400 1998.10.14, Vincent Nonnenmacher wrote:
>Let me try to rexplain what I was try to say two weeks ago.

I kinda follow, I think.  Are you just saying that you want to make sure
there is a good, simple way to get at record lists of properties?

That is something I am working toward.  I personally think such things in
Apple Events are deficiency in the design, but c'est la vie.


>>Anyway, I also changed the _obj() method to simply o(), and _prop()
>>(property) is p().  I know those are not the clearest of names, but they
>>could be called often enough that Shorter Is Better.  I think so, anyway.
>>You tell me.
>
>I personaly dislike meaningless method names but this is your choice.

Well, maybe it is ultimately my choice, but that is not the point.  I am
open to arguments either way.  My motivation is that _prop and _obj, in
addition to the object itself and the arrow operator, can get to be a lot
of typing, and can be harder to read.  I am open to suggestions.  Although,
I must contend the names are not at all meaningless; o => object, p =>
property.  :-)



>I think that every scripter will need a way to :
>
>1) specify all the possible selection criteria and get an error when the
>glue can't make an objecft specifier from the class hash.
>
>2) save for further reuse in perl an object reference the referecne
>specifier that OSL give back umodified to make further script object ->
>real app object mapping.
>
>3) have a way to grab a list of objects from a returned reply and use
>thoses as futur object specifier for further processing (like get all
>elements that match a test (range, boolean exp etc)

Seems I am providing all these already (in the version I am working on that
I reported on, of course).  Did you mean something different than what I am
providing?


>4) build an on the fly AE 'rec' record from any valid class type augmented
>with class defined by the application.

Are you referring to the stuff about record lists above?


>During my investigation of simple and Glue I was just wondering if a whole
>different approach could be to simply build AEGizmo expressions using the
>glued file and fire them to it instead of building the AEDesc by hand. It
>would be much faster and perhaps more simplier to debug an any stage of the
>process because they would be strings.

I don't think it would be _much_ faster; I see no evidence of that.  I
suspect any speed increase would be modest at best.  I am already using
some of the AEGizmo functions; AEBuildAppleEvent is from AEGizmos (in fact,
the Simple module does use all AEGizmo stuff for bulding events, in one
single AEBuildEvent call).

As to simpler to debug, I don't see how; dealing with strings IMO makes it
harder to debug and easier to make mistakes.  I am not saying your idea has
no merit, but in the time I've been working with this stuff, I've had
better luck dealing with the raw Apple Event functions.

I suppose for most parameters it isn't as much of an issue, but when
constructing objects, I find the raw AE interface the easiest.  Dealing
with strings in that manner is a real pain, and error-prone.  That's
probably the biggest reason why I use the raw calls: because of object
specifier records, which I really don't want to build as strings.

I don't like the streams method at all, so that is out.  :)

I will think on it, though I must confess the specific implementation of
building the events is not important to me right now as much as the overall
design is; whatever the implementation of the build calls, the overall
design would remain mostly unaffected.  I will think more on it, but not
for a little while; I want to get the design down.  So thanks for giving me
more to think about.  :-)

--
Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch