Re: Libraries and effiency
Re: Libraries and effiency
- Subject: Re: Libraries and effiency
- From: Tommy Bollman <email@hidden>
- Date: Tue, 10 Aug 2010 15:54:48 +0200
Hello.
>>
>> I think OSAX should be included, and when I see those kinds of commands in the dictionary I react the same way as if a developer put the "File" menu where the "Help" menu should be. I also wonder if they can't get that right, what else have they gotten wrong?
>
> Hey Ed,
>
> Get real buddy. The bottom line for professional users is that things work reliably 24/7. I have 3 Macs on my desk bought and paid for with a portion of the fees for some FCP and QT osaxen I wrote last year. Those clients don't pay for bugs like terminology conflicts. Since one can't ever guess what another osax on some arbitrary user's system will name their terms, the only way to avoid those kind of bugs in advance is to use a prefix.
>
> End of story.
I think you could store an offending/annoying osax in an application bundle,/ScriptLibraryServer and address that osax within a tell block
to the application. The osax would need to be stored in a Scripting Additions folder (remark the space) and the routines that leverages on it, in the Application I believe. ( in the main script ).
On 10 Aug 2010, at 14:10, Philip Aker wrote:
> On 2010-08-09, at 10:09:25, email@hidden wrote:
>
>>> I think I can only agree with your school-marm-like finger wagging in the case of applications so yes, I should have been more specific.
>
>> I think OSAX should be included, and when I see those kinds of commands in the dictionary I react the same way as if a developer put the "File" menu where the "Help" menu should be. I also wonder if they can't get that right, what else have they gotten wrong?
>
> Hey Ed,
>
> Get real buddy. The bottom line for professional users is that things work reliably 24/7. I have 3 Macs on my desk bought and paid for with a portion of the fees for some FCP and QT osaxen I wrote last year. Those clients don't pay for bugs like terminology conflicts. Since one can't ever guess what another osax on some arbitrary user's system will name their terms, the only way to avoid those kind of bugs in advance is to use a prefix.
>
> End of story.
>
>
>> Terminology conflicts are fairly rare and fairly easy for the "Osax" developer to avoid.
>
>>> Otherwise, my suggestions hold. For example can easily realize the lure of using the obvious "import" and "load library" in an OSAX only to discover that developer B has used the same terms in his.
>>>
>
>>> To this effect, I have filed a bug for osaxen to at least have the ability to be addressed something like:
>>>
>
>>> tell osax id "ca.aker.osax.WCHandy"
>
>
>>> so as to eliminate the possibility of terminology conflicts.
>
>> At this point the "OSAX" become a FBA and should be developed and distributed as such, which is probably the best way to go for the library loaders.
>
> Cow patty.
>
> If someone pays for an OSAX, it means they don't want an FBA. Speed counts in the video world.
>
>
> Philip Aker
> echo email@hidden@nl | tr a-z@. p-za-o.@
>
> Democracy: Two wolves and a sheep voting on lunch.
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> AppleScript-Users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> Archives: http://lists.apple.com/archives/applescript-users
>
> This email sent to email@hidden
>
Best regards
Tommy Bollman
--------------------------------------------------------------------------------------------------
Mollison's Bureaucracy Hypothesis:
If an idea can survive a bureaucratic review
and be implemented it wasn't worth doing.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden