Re: Dictionary possibilities [Re: Interesting... AppleScript X??]
Re: Dictionary possibilities [Re: Interesting... AppleScript X??]
- Subject: Re: Dictionary possibilities [Re: Interesting... AppleScript X??]
- From: has <email@hidden>
- Date: Sat, 28 Sep 2002 00:54:54 +0100
Michael Kelly wrote:
>
> [smart object-centric editors]
>
>
Wouldn't this then limit users to editing AS source with Apple's provided
>
editor?
Well, I never stated anything as to the structure of the editor/editing
environment. It might be a monolithic, proprietary, single-vendor
application keyed into a closed language format. Or there could be core
engine provided as framework/system extension that anyone can adopt as the
foundation to their own visual editor whilst being left to build the rest
however they see fit. Or perhaps there'd be nothing more to it than an open
language format, with developers welcome to create their own tools from
scratch.
So the answer would be [bearing in mind we're talking purely in
hypotheticals here]: "only if Apple _wanted_ it that way". I would consider
it a foolish choice if they did, personally. Here's a good take on the
issue of whether to allow others to play in your sandpit or not:
<
http://www.joelonsoftware.com/articles/Platforms.html>.
--
>
Isn't using plain-text source an _advantage_
The strength of plain-text source is that it's the lowest common
denominator. The weakness of plain-text source is also that it's the lowest
common denominator.
If you use plain-text source, you have portability across all the
plain-text editors that exist today. [At least until The Unicode Issue
sorts the men from the boys; probably lose a few of them over that, but
never mind.]
However, you also limit the range and types of editing environments you can
ultimately create. Text-based source is kind of an after-the-fact thing; to
get anything useful done with it, you have to type it, parse it, tokenise
it, turn those tokens into a lot of different types of nodes in a great big
tree structure, and then do whatever else it is you're going to do before
finally spewing out bytecode, machine code, or whatever. If you want to do
anything "live", i.e. as source code is entered, I suspect you'll have to
trowel on a load of extra stuff and/or seriously rework your compiler to
support that. I also wonder what sort of additional load that might impose
on the system, having to constantly churn away on material that was never
designed to support such behaviour.
With a live, object based environment, you don't need any of that
parsing/tokenising stuff, and you can go straight to the object model bit.
Your object can be smart and as helpful as you like: for example, they
could provide the user with a list containing all the
objects/functions/variables that are currently available to them at the
point they're working at; no more "The variable foobasr is undefined"
messages ever again. Components can be connected by drag-n-drop; not just
graphical widgets as in IB, but handlers, classes, properties, etc. too.
Components from external sources can be viewed and worked with as if local.
Code can be visualised in multiple ways: as text, as outliner, as 3D
spinning graphical model even; and you'd be able to interact with it in any
one of those states. You can ditch your separate debugger too: flip a
switch, and all your variable objects become viewers showing their current
state, and you can watch them change while the system test-runs. You can
bind your unit tests to the classes they're used with. Structured
documentation can become a first-class component of any code.
I could go on and on, you know, but at this rate some absolute stinker from
out of town is going to see all these cool ideas I'm merrily spewing out,
nip over to the US Patent Office with a quick printout wrapped in a hundred
dollar bill, and then I'll never see them again... so consider this prior
art, if you will, and that I've said more than enough already. BTW, I'm
still for hire, if anyone's interested. ;)
...
So sure, you could probably make a text-based system do all these sorts of
things too, if you really tried. Question is: would you ever want to? On
the other hand, once you start thinking what the possibilities of change
might be, do you really want to stay exactly as you are for the rest of
eternity?
Technology and innovation marches inexorably along, one hopes. And
occasionally it has to leave a few old friends behind if it's to make the
next leap forward.
Cheers,
has
--
http://www.barple.pwp.blueyonder.co.uk -- The Little Page of AppleScripts
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.