[openbeos] Hey and scripting
- From: Michael Phipps <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 07 Jun 2006 22:38:38 -0400
Charlie Clark wrote:
Actually this is more on topic that Haiku's new killer app - a calculator!
;-)
hey's syntax is a problem - scripting applications from the shell is a
nightmare. But the real problem is the lack of handles and hooks in
applications in order to be able to get them to do things. I think real
programmers call hey directly from within C++ programs which makes a lot of
difference. Done properly hey provides a lovely bridge for remote control
of applications without the need for a new language and all the associated
pitfalls.
As much as I would like to agree with my distinguished colleague, I am
afraid that I can not do so in good conscience.
The biggest issue is that most apps are not written in a client server
manner. This design prevents clean and clear scripting to begin with.
This is, incidentally, the problem with porting apps. The way that
windowing works in Haiku/BeOS makes it sort of necessary to think of
your windows as an entity in and of themselves that manage themselves.
App logic is it's own entity. Personally, I think (and when I do write
apps...) that you should be able to build your app, most of the time,
into a GUIless state and control it totally via Hey. Or a simple command
line that sends BMessages to your app. Or a GUI that uses that same
messaging API.
Right now, apps are often written much like Windows/Unix apps where the
work is done in the same thread as the window. That prevents Haiku from
really shining in the multi-threaded goodness that it should have. :-)
I just looked through a good sized pile of Be's sample code. Some apps
do this, others don't (mostly the smaller ones).
As a side note - I doubt that many BeOS/Haiku apps message each other,
but when they do, it is done using BMessage, not Hey.
But, this leads me into what I think is a more interesting topic...
I don't agree that Hey's syntax is the issue - I think that Hey has a
good syntax for what it does. I think that the real issue is that the
BeOS scripting stuff is inadequate. Specifically, I think that the
reflection that exists needs parameters and return values, optional
parameters and probably better descriptions of what the parameters are
and do. Right now, you can say "hey foo getsuites" and find out what
methods and properties there are. You can't really find out what
parameters those methods take or what they return. Without those things,
you can't really know how to script something without external
documentation. You could sit there all day and guess at what message
data you need to run some looper.
Now, having said all of that, I would think that the next step would be
to make some standard templates that the OS objects would adhere to;
every translator has a "NativeFormat" property, for example, that would
return strings of the mime types of the formats that it natively
translates. Then a thin C++ wrapper could make the OS accessible to any
language that supports reflection based APIs and enough C++ to get
BMessages...
But that is just my dream, I suppose.
Other related posts:
- » [openbeos] Hey and scripting
