Python component model

[Dennis Lee Bieber]

I guess I'm too dumb to understand the question... Does pickle not work
for you? What is a "persistency binding"?

Coming in from left-field... I'd interpret it to mean that the
"component model" ITSELF handles storage/retrieval of the objects
created essentially transparent to the user. Similar to how a "shelve"
(sp?, haven't used one) looks like a plain dictionary in Python, but
really saves the contents in a persistent file. So I'd expect your
"components" to maybe have parallel invocations which save state
externally (I'll have to confess I've not studied the model under
consideration, I'm just working from snippets of this discussion), or
some sort of semi-global flag that enables/disables such persistency for
all...
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Jacob Hallen]

functions at ever higher levels of abstraction, or to have a
proliferation of nebulously-defined "manager" objects.) IMHO once you
cross this chasm and are able to model your problem domain with live
objects that go off and automatically respond to the runtime
environment and Do the Right Thing, it's very hard to go back to a dead
object mindset. I can understand, however, that until one makes this
leap, it might seem like an academic and useless distinction.

I'm not disagreeing with the blessings of components reacting to events
and going off Doing the Right Thing. However, there is a huge with
components going off Doing the Wrong Thing. It becomes exceedingly
hard to debug for several reasons. The first one is that it is difficult
to trace the callbacks generated, since the point where they were
registered is no longer trackable when your problem occurs. The second
and most serious problem is that erroneous behaviour in two components
can interact in extremely mysterious ways that are really difficult to
debug.

In part these problems can be reduced by much rigorous testing of each
component than is the norm today, but for the really tough problems we
need tools that have not been invented yet, that track the history
of each callback. Since these tools have to understand the details
of the calling conventions and registration mechanism for events, they
have to be custom built for each component framework and should therefore
be part of the framework distribution.

Jacob Hallén

--

 

[sturlamolden]

Having never used java or .NET I'm not sure what you're looking for.

There is a whole generation of computer users out there scared stiff of
using the keyboard. Soon, computers will not have a keyboard at all.
The trend is perhaps more pronounced among managers not writing code
themselves, but "taking decisions" about which tools to use.

The answer to these needs are so-called "RAD tools" like Borland
Delphi, Visual Basic, Visual C# .NET, and perhaps Java's NetBeans.
Instead of writing code, a "programmer" selects "components" from a
menu, drags the component over a "form" and then drops it onto the
"form". A form can e.g. be a web page, a GUI window or just an
invisible abstract container in case the program doesn't have a visual
interface. Components can be visual GUI widgets like buttons and
sliders, but also "invisible" objects like files and sockets. Instead
of creating a file by typing "open" one would "drag 'n drop" a "file
component" from a menu onto the form, and then type in the name in some
sort of "property menu" for the component. If one needs a tcp socket,
one don't type "s = socket(...)" in the code but select an socket from
a menu and drop it over a form.

In order to do this, a RAD tool need some sort of standardised
component model. Sure, it must be able to inspect the component, but
also interpret the methods and members that it finds. The RAD tool must
be able to inspect the model to find out what to "publish" in the
property menu, what event it generates, etc. Typical component
standards used for this is ActiveX (in Visual Basic), .NET in Visual
C#, VCL in Delphi, and JavaBeans in NetBeans. If you build a component
that does not follow the standard, the RAD tool can't use it. For
example in JavaBeans, every pair of method that looks like
"component.setSomething(...)" and "component.getSomething(...)" is
parsed by the RAD tool as the property "Something" and put into the
property meny for the component. The programmer can change the value of
this property by typing into the property menu.

The most extreme RAD tool is LabView, where no code is written at all,
not even event handlers which are still hand coded in the other RAD
tools. In labView, everything is "dragged and dropped", and the dropped
components are connected by "cables" just like a circuit board. There
are even "components" encapsulating for and while loops. If you need a
while loop, you drop a while loop onto the form. If you need a
subroutine, you drop a subroutine onto the form, etc. Nothing is typed.

Does Python need a standard component model like ActiveX, VCL, .NET or
JavaBeans?

First, there are GUI designer's for Python. These include GLADE, QT
Designer and wxGlade. We don't need a Python object model to support
GUI designers. Second, are we really that scared of writing code? Some
obviously are. Why is dropping a socket component preferred over typing
"socket"? Those that want LabView or Visual Basic knows where to find
it.

Python already has "properties". What Python don't have is "events",
but that can be easily implemented (and is implemented in all GUI
toolkits) e.g. using exceptions and references to functions. En event
can be raised by raising an exception. Perhaps we should define an
standard "event" interface just to shut them up? Then we have a
"component model".

 

[Magnus Lycka]

There is a whole generation of computer users out there scared stiff of
using the keyboard. Soon, computers will not have a keyboard at all.
The trend is perhaps more pronounced among managers not writing code
themselves, but "taking decisions" about which tools to use.

Is it just me, or does someone else feel that this is like
using magnetic letters on a refrigerator door instead of
a pen and paper. My two year old son thinks those magnetic
letters are fun, but then he can't write at all. My seven
year old has certainly switched to pen and paper (or computer)
for 99% of his writing. Sure, they have their use--it might be
more effective to write TENNIS with colorful letters across
the fridge door in some situation, but most of the time, pen
and paper is much more useful. You never run out of letters,
and it's easy to draw lines or arrows, complement the text
with a little picture etc. The cost for learning the skill
to write readable letters is well compensated for...

We recently released a toolkit for interfacing our systems
with legacy systems, and very soon, people started using it
in way we had never expected. I suppose that could be possible
with a "visual" tool too, but it seems to me that those tools
are typically fairly limited, just as computer based role-playing
games are much more limited than the ones played around a table
with a good flesh-and-blood game master who can respond to any
idea you come up with at the spur of the moment.