frames instead of objects!
Cris A Fugate
simply because I prefer to use frames instead of objects. Frames
are more dynamic than objects and objects simply do not fit into
my vision of Tcl as a tool for artificial intelligence, the reason
for my coming to Tcl in the first place.
Sure you can say that I can just delete [incr]tcl from the distribution,
but the fact is that once it makes it that far it will *contaminate*
other extensions.
I am extremely fearful that this complaint is for not and that
people already have their minds made up. I could tightly bind
framesets (see http://sites.netscape.net/tclframes/index.html)
into the core, but this would create a fork in the Tcl language.
I could also refuse to use any new release, but that might leave
me out of new developments. I could also create a new language
based on frames. Or, we could modify [incr]tcl and framesets
so that there is some compatibility between the two at some level.
Does anybody have thoughts on this?
--
**********************************************************************
Cris A. Fugate Lucent Technologies, Robust Process Automation
fug...@lucent.com http://ihgpweb.ih.lucent.com/~fugate
630 713-8255 Creator of framesets, a frames implementation
Andreas Leitgeb
>Does anybody have thoughts on this?
yes:
What has an OO-extension to tcl got to do with frames ?
Cris A Fugate
slots. Each slot contains data, method, or a reference to another
frame, and demons which are automatically called depending upon
the type of action performed on a slot. Slots can be created, modified, removed
from a frame at anytime without the need of classes.
With framesets, frames (and frame sets) can be grouped together and
managed together. So such frames could have a common structure, but
also have additional slots.
What does an object-oriented Tcl got to do with frames? It is
obviously an alternative data structure which fills overlapping
applications. I personally dont want or need an object-oriented language.
Another thought is to extend framesets to convert objects into
frames. Although I don't know how this would affect widgets except
maybe as a frontend to grouping widgets together?
Bryan Oakley
news:3A195978...@lucent.com...
> I am very much opposed to putting [incr]tcl into the core of Tcl
> simply because I prefer to use frames instead of objects. Frames
> are more dynamic than objects and objects simply do not fit into
> my vision of Tcl as a tool for artificial intelligence, the reason
> for my coming to Tcl in the first place.
>
> Does anybody have thoughts on this?
My thoughts are this, in no particular order:
1) superior technology (if that what the frames vs. [incr tcl] argument
boils down to) rarely seems to win in the marketplace. Mindshare and
perception and "good enough" often stand the tallest at the end of the day
(witness Microsoft vs. Apple (and unix and linux and ...), VHS instead of
BETA, etc. ad infinitum)
2) something is better than nothing.
3) [incr tcl] is much more widely used than your frame implementation, and
thus more likely to be accepted by the target audience of tcl users
4) there's no technical reason why *both* couldn't be included in the core,
if a good argument could be made for doing so.
--
Bryan Oakley Vignette, Corp
boa...@vignette.com http://www.vignette.com
http://purl.oclc.org/net/oakley
faat...@my-deja.com
"Bryan Oakley" <boa...@vignette.com> wrote:
> "Cris A Fugate" <fug...@lucent.com> wrote in message
> news:3A195978...@lucent.com...
> > I am very much opposed to putting [incr]tcl into the core of Tcl
> > simply because I prefer to use frames instead of objects. Frames
> > are more dynamic than objects and objects simply do not fit into
> > my vision of Tcl as a tool for artificial intelligence, the reason
> > for my coming to Tcl in the first place.
> [snip]
> >
> > Does anybody have thoughts on this?
>
> My thoughts are this, in no particular order:
>
> 1) superior technology (if that what the frames vs. [incr tcl]
argument
> boils down to) rarely seems to win in the marketplace. Mindshare and
> perception and "good enough" often stand the tallest at the end of
the day
> (witness Microsoft vs. Apple (and unix and linux and ...), VHS
instead of
> BETA, etc. ad infinitum)
>
The race Microsoft vs. Linux just started.
- faatdilac
> 2) something is better than nothing.
>
> 3) [incr tcl] is much more widely used than your frame
implementation, and
> thus more likely to be accepted by the target audience of tcl users
>
> 4) there's no technical reason why *both* couldn't be included in the
core,
> if a good argument could be made for doing so.
>
> --
> Bryan Oakley Vignette, Corp
> boa...@vignette.com http://www.vignette.com
> http://purl.oclc.org/net/oakley
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
jay
Cris A Fugate <fug...@lucent.com> wrote:
> I am very much opposed to putting [incr]tcl into the core of Tcl
> simply because I prefer to use frames instead of objects. Frames
> are more dynamic than objects and objects simply do not fit into
> my vision of Tcl as a tool for artificial intelligence, the reason
> for my coming to Tcl in the first place.
So don't use [incr tcl]. It's not like a mountain; you don't have
to use it just because it's there. I would expect you will be
able to continue using frames just like you had before, barring
any compatibility issues.
No one will force you to use objects just because [incr tcl]
is there.
No one is forcing you to use tcllib either, but sure enough,
it's there.
> Sure you can say that I can just delete [incr]tcl from the
> distribution, but the fact is that once it makes it that far
> it will *contaminate* other extensions.
And what's wrong with that? If other extensions use it, it will
be there. So no problem. I would think the only problem would
occur if you deleted it from the distribution. I would think if
you use other extensions, and you don't have to do anything
special to get them to work, that you wouldn't have any problems.
Now, if you were using an extension, and that extension was
updated to use [incr tcl], and you didn't want to update your
Tcl distribution, I could see where you might be concerned. But
updates to software are a fact of life. And you either update
and accept the dependencies, or you stay where your at. I think
I've seen posts from people still using Tcl 7.2 or 7.3, and hey,
that's fine. No one is forcing you to update.
> I am extremely fearful that this complaint is for not and that
> people already have their minds made up. I could tightly bind
> framesets (see http://sites.netscape.net/tclframes/index.html)
> into the core, but this would create a fork in the Tcl language.
> I could also refuse to use any new release, but that might leave
> me out of new developments. I could also create a new language
> based on frames. Or, we could modify [incr]tcl and framesets
> so that there is some compatibility between the two at some level.
>
> Does anybody have thoughts on this?
I guess I don't understand why you're concerned about it. I've
actually looked at your frameset stuff some time ago, perhaps
when you first posted about it, and thought it looked neat. But
I never did anything with it. Pretty much the same story for
[incr tcl] -- looked neat, never used it.
No one forced me to use [incr tcl]. And no one forced me to
use framesets. And regardless of whether or not they were
bundled in the core, I wouldn't use them unless I needed to
or simply wanted to.
Are you viewing [incr tcl] as a competing technology? Are you
concerned that someone might use objects to explore AI with tcl
instead of using your framset extension? Are you concerned that
changes made to the core to enable [incr tcl] will somehow prevent
you from upgrading your frame extension to work with newer
releases? What, specifically, is the issue?
: jay
--
Using self-discipline, see http://www.eiffel.com/discipline
Mo
> I am very much opposed to putting [incr]tcl into the core of Tcl
> simply because I prefer to use frames instead of objects.
So, continue to use frames. If you don't like classes, don't
use them. What is the problem?
> Sure you can say that I can just delete [incr]tcl from the distribution,
> but the fact is that once it makes it that far it will *contaminate*
> other extensions.
I sure hope so. If by *contaminate* you mean that people will be
able to write OO based extensions that do not require additional
native extensions. That is a very good thing, Tcl has been without
OO for far too long. Indexing into global arrays is a big hack
and doing that in your own OO wrapper is just too darned slow.
> I am extremely fearful that this complaint is for not and that
> people already have their minds made up.
Well, I think OO in Tcl is a very good thing. I am willing to
hear your arguments on how that should be implemented.
> I could tightly bind
> framesets (see http://sites.netscape.net/tclframes/index.html)
> into the core, but this would create a fork in the Tcl language.
Forks are good. They feed the hungry.
> I could also refuse to use any new release, but that might leave
> me out of new developments. I could also create a new language
> based on frames. Or, we could modify [incr]tcl and framesets
> so that there is some compatibility between the two at some level.
Those all sound like reasonable options, but you left one out.
You could use the new Tcl but continue to make use of your
own frame extension.
Mo DeJong
Red Hat Inc
lvi...@cas.org
:In article <3A195978...@lucent.com>,:> Sure you can say that I can just delete [incr]tcl from the
:> distribution, but the fact is that once it makes it that far
:> it will *contaminate* other extensions.
The only way that the contamination will impact you is if incr tcl is
included in such a way that it prevents you from implementing frames.
So far, all I have heard from people opposing the itcl inclusion is
FUD - Fear Uncertainty and Doubt. The best way to resolve these feelings
is for a) someone proposing the inclusion of itcl into the core to
detail EXACTLY what the resulting Tcl core would be like and b) those
afraid of the inclusion to detail EXACTLY how this change would prevent
them from implementing their code.
In my opinion, there's one way that things could go bad - if existing
core functionality changes in some dramatic way to prevent your existing
implementation to no longer be valid - or if the infrastructure (for,
if, etc.) were to change to require the use of the functions. Until
someone expressions such intent, then I would not expect it to occur.
It's interesting that we didn't really have all this FUD when sockets
were added to the core, or even Unicode...
--
"See, he's not just anyone ... he's my son." Mark Schultz
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Andreas Leitgeb
> ... b) those
>afraid of the inclusion to detail EXACTLY how this change would prevent
>them from implementing their code.
there are some (not me) who simply do not like itcl. and anything
that will bring itcl *closer* to them is bad in their eyes.
And yes, there's no doubt that although itcl will not necessarily
have an influence on the core, it's tighter bundling with tcl will have
an influence on it's usage in new tcl-code/extensions. And that is
what they oppose.
the question is not, "how this change would prevent them from implementing
their code", but whether they really think that they can stop the
train going towards OO, or whether, if the train could really be
stopped, people wouldn't get off the train and walk (= other languages)
instead, to get nearer to OO.
lvi...@cas.org
According to Andreas Leitgeb <a...@logic.at>:
: there are some (not me) who simply do not like itcl.
What does this mean? You mean a) you don't like any of the concepts presented
in the incr tcl package, b) you don't like the way the concepts were
implemented, or c) something else?
Secondly, how would you propose that an open source community resolve issues
where one group of particularly vocal people want a change and a second
vocal group do not want a change? Should the community stop including
code everytime there are suggestions - even ones that are basically, as you
say "I don't like it"? So, if I say "I don't like Tk" we should stop
including Tk? If I say "I don't like Unicode, threads, regular expressions,
sockets, file i/o, and the byte compiler" then we should rip those out as
well? Where do we stop - when there is nothing left in Tcl?
:the question is not, "how this change would prevent them from implementing
:their code", but whether they really think that they can stop the
:train going towards OO, or whether, if the train could really be
:stopped, people wouldn't get off the train and walk (= other languages)
:instead, to get nearer to OO.
:
People already are getting off the train and walking. That's a fact. We've
seen postings here as well as papers presented where people have moved from
Tcl to Python because of a lack of bundled OO as well as the lack of
included packages.
In MY mind, the question is NOT at all "will people leave because something
is present or missing from the language" - because the answer to that question
is ALWAYS going to be yes... until there is no one left. The question for
me is "does the change provide Tcl with an improvement that is otherwise not
possible, or at the very least, quite difficult, to obtain".
It's too bad that the TCT isn't using that as the primary means for determining
whether something goes into the core.
However, as a community, I believe that we should ask the TCT to document
a set of objective criteria by which decisions on whether something goes
into the set of source files that exist under the tcl (or tk for that
matter) source tree. Otherwise, everytime someone proposes something
go in we have the potential for these 6-12 month debates...
lvi...@cas.org
According to Mo <m...@nospam.com>:
:Cris A Fugate wrote:
:> Sure you can say that I can just delete [incr]tcl from the distribution,
:> but the fact is that once it makes it that far it will *contaminate*
:> other extensions.
:I sure hope so. If by *contaminate* you mean that people will be
:able to write OO based extensions that do not require additional
:native extensions.
By contaminate he means that the tcl source directory will become dependant
on the OO constructs embedded, so that one is no longer able to implement
a Tcl extension implementing some other, incompatible, version of OO.
:> I could tightly bind
:> framesets (see http://sites.netscape.net/tclframes/index.html)
:> into the core, but this would create a fork in the Tcl language.
:
:Forks are good. They feed the hungry.
For that matter, there are several features in Tcl now that came after
forks in Tcl were created, promoted, became popular, and the fork merged
back in. Please - rather than all the handwriting, start promoting your
alternative OO extensions. Write articles talking about what one can
do in your extension. Show code demonstrating how to use your OO extension
to solve problems. When people ask how to code something, use your OO
extension to demonstrate how nicely things look in your extension. Only
by showing us, on a regular basis, the benefits of your extension (and
by benefits I don't mean flaming the other extensions) can anyone see
the light and become another supporter of your extension.
:You could use the new Tcl but continue to make use of your
:own frame extension.
As long as his own frame extension can continue to be built. That's one
of the primary fears that I have read over the last 3 waves of these
discussions. People fear the unknown. Until the advocates of incorporating
itcl into the core provide a forked version of Tcl showing us what the
intended environment is, or at least provide a detailed spec of the intended
changes, authors of alternative OO environments are going to fear being
shut out of the community.
Andreas Leitgeb
>According to Andreas Leitgeb <a...@logic.at>:
>: there are some (not me) who simply do not like itcl.
>What does this mean?
[three wrong interpretations snipped]
oh gosh, I really need to take a proper english-course titled:
"How to write understandable english" ...
I meant that some vocal ones didn't like OO (itcl) ...
and that I'm *not* one of these.
please, reread my previous posting now.
>People already are getting off the train and walking.
yes, true, and it's a bad thing.
The same unfounded general resistance against new features has also
so far killed the "{expand}$" proposal ...
Cris A Fugate
implementation of framesets in any future release of Tcl. What I
am concerned about is the prolific misuse of [incr]tcl if it is
put into the core. I do not want Tcl to become another Python or
Java! (Nevermind the fact that framesets cannot be implemented in
either of these two languages).
I can still here my OO professor saying that everything could be
programmed with objects. It may be true, but it certainly isn't
desireable for the simple fact that objects are too static.
That is where frames comes to the rescue. On the other hand,
the architecture of frames is very open and although this is
useful, it can also be a danger..
Dan Smart
<slrn91lch...@pc7499.gud.siemens.at>:
>
>I meant that some vocal ones didn't like OO (itcl) ...
>and that I'm *not* one of these.
>
>>People already are getting off the train and walking.
>yes, true, and it's a bad thing.
>
But that probably has more to do with the absence of a batteries included
*binary* distribution for their platform than this months missing feature
du jour.
>The same unfounded general resistance against new features has also
> so far killed the "{expand}$" proposal ...
No. A specific resistance to ill-thought out kludges has I hope killed the
{expand} proposal.
Dan "Terse" Smart.
--
Dan Smart. C++ Programming and Mentoring.
cpp...@dansmart.com
Bruce Stephens
[...]
> I can still here my OO professor saying that everything could be
> programmed with objects. It may be true, but it certainly isn't
> desireable for the simple fact that objects are too static. That is
> where frames comes to the rescue. On the other hand, the
> architecture of frames is very open and although this is useful, it
> can also be a danger..
I can see this. Similarly, XOTcl looks attractive. But [incr Tcl] is
attractive too: it's similar enough to C++ and Java for the
similarities to be useful.
What would be really nice would be a minimal addition to Tcl,
sufficient conveniently to build megawidgets (including whatever's
necessary for the focus problems and whatever), but flexible enough so
that one could implement both B&D systems like [incr Tcl]'s and more
dynamic systems like XOTcl's (or your frames)---and make the
implementations sufficiently efficient that everyone would be happy,
of course.
I'm not at all sure that such a thing is possible, but I'm not too
pessimistic. Probably something not too different to this frames idea
would do the trick. Or XOTcl---I'm sure one could build something
like [incr Tcl] using XOTcl pretty easily (or just use XOTcl in an
[incr Tcl]-like way), and I suspect it wouldn't be too different in
performance for anybody to notice.
fri...@my-deja.com
> implementation of framesets in any future release of Tcl. What I
> am concerned about is the prolific misuse of [incr]tcl if it is
> put into the core. I do not want Tcl to become another Python or
> Java! (Nevermind the fact that framesets cannot be implemented in
> either of these two languages).
>
> programmed with objects. It may be true, but it certainly isn't
> desireable for the simple fact that objects are too static.
This is your opinion and you can work at convincing others that
this is the case, preferably with coding examples of interesting
problems. Personally I regard frames as a specific AI technique which
has its place but which is usually not seen as a general programming
paradigm.
The currently most widely known and used programming
paradigm, however, is (I.M.H.O.) the OO paradigm. Moreover, it is my
impression that many people do not consider tcl or consider moving away
from tcl because of the lack of OO. Indeed, keeping state in global
arrays has severe limits for larger programs.
I hope the discussion on incr tcl will converge *very soon* and incr
tcl will be moved into the core. Each additional month of discussion
will decrease tclæ„€ mindshare. Stated positively, I assume that an
object-oriented tcl will generate a large increase in usage and
visibility.
Let us make a decision - now!
Bernd Fritzke