Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #37144 > unrolled thread

Object-Oriented Programming (OOP)

Back to article view | Back to comp.lang.forth

Contents

  Object-Oriented Programming (OOP) Steve Graham <solitary.wanderer52@gmail.com> - 2015-03-10 18:17 -0700
    Re: Object-Oriented Programming (OOP) Melzzzzz <mel@zzzzz.com> - 2015-03-11 02:21 +0100
      Re: Object-Oriented Programming (OOP) Richard Owlett <rowlett@cloud85.net> - 2015-03-11 06:25 -0500
        Re: Object-Oriented Programming (OOP) Mel <mel@zzzzz.com> - 2015-03-11 14:49 +0100
    Re: Object-Oriented Programming (OOP) "Elizabeth D. Rather" <erather@forth.com> - 2015-03-10 15:43 -1000
      Re: Object-Oriented Programming (OOP) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-11 10:05 +0000
        Re: Object-Oriented Programming (OOP) "Elizabeth D. Rather" <erather@forth.com> - 2015-03-11 13:48 -1000
      Re: Object-Oriented Programming (OOP) Hans Bezemer <the.beez.speaks@gmail.com> - 2015-03-12 19:01 +0100
        Re: Object-Oriented Programming (OOP) Pete Brown <brown.peter@nospicedham.com> - 2015-03-12 18:09 +0000
          Re: Object-Oriented Programming (OOP) Hans Bezemer <the.beez.speaks@gmail.com> - 2015-03-12 23:46 +0100
            Re: Object-Oriented Programming (OOP) Doug Hoffman <glidedog@gmail.com> - 2015-03-13 15:50 -0400
              Re: Object-Oriented Programming (OOP) Mark Wills <markwills1970@gmail.com> - 2015-03-13 14:24 -0700
                Re: Object-Oriented Programming (OOP) "Alex McDonald" <blog@rivadpm.com> - 2015-03-14 18:17 +0000
                Re: Object-Oriented Programming (OOP) Doug Hoffman <glidedog@gmail.com> - 2015-03-16 06:30 -0400
    Re: Object-Oriented Programming (OOP) Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-11 03:16 +0100
    Re: Object-Oriented Programming (OOP) Doug Hoffman <glidedog@gmail.com> - 2015-03-11 10:18 -0400
      Re: Object-Oriented Programming (OOP) Steve Graham <solitary.wanderer52@gmail.com> - 2015-03-11 09:01 -0700
        Re: Object-Oriented Programming (OOP) Doug Hoffman <glidedog@gmail.com> - 2015-03-11 13:16 -0400
    Re: Object-Oriented Programming (OOP) november.nihal@gmail.com - 2015-03-11 08:03 -0700
    Re: Object-Oriented Programming (OOP) Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-03-12 00:57 +0000
      Re: Object-Oriented Programming (OOP) "Elizabeth D. Rather" <erather@forth.com> - 2015-03-11 18:31 -1000
        Re: Object-Oriented Programming (OOP) Mark Wills <markwills1970@gmail.com> - 2015-03-12 01:51 -0700
    Re: Object-Oriented Programming (OOP) franck.bensusan@gmail.com - 2015-03-12 07:04 -0700
      Re: Object-Oriented Programming (OOP) "WJ" <w_a_x_man@yahoo.com> - 2015-03-16 18:10 +0000
        Re: Object-Oriented Programming (OOP) franck.bensusan@gmail.com - 2015-03-16 11:39 -0700
          Re: Object-Oriented Programming (OOP) Doug Hoffman <glidedog@gmail.com> - 2015-03-16 17:30 -0400
            Re: Object-Oriented Programming (OOP) franck.bensusan@gmail.com - 2015-03-16 15:51 -0700
          Re: Object-Oriented Programming (OOP) "WJ" <w_a_x_man@yahoo.com> - 2015-03-16 22:35 +0000
            Re: Object-Oriented Programming (OOP) franck.bensusan@gmail.com - 2015-03-16 15:54 -0700
    Re: Object-Oriented Programming (OOP) Doug Hoffman <glidedog@gmail.com> - 2015-03-13 11:45 -0400
      Re: Object-Oriented Programming (OOP) hughaguilar96@gmail.com - 2015-03-14 13:52 -0700
        Re: Object-Oriented Programming (OOP) Doug Hoffman <glidedog@gmail.com> - 2015-03-15 07:01 -0400
          Re: Object-Oriented Programming (OOP) hughaguilar96@gmail.com - 2015-03-15 18:16 -0700
            Re: Object-Oriented Programming (OOP) Doug Hoffman <glidedog@gmail.com> - 2015-03-16 05:50 -0400
              Re: Object-Oriented Programming (OOP) Doug Hoffman <glidedog@gmail.com> - 2015-03-16 08:54 -0400
                Re: Object-Oriented Programming (OOP) hughaguilar96@gmail.com - 2015-03-16 10:23 -0700
            Re: Object-Oriented Programming (OOP) november.nihal@gmail.com - 2015-03-16 09:02 -0700
              Re: Object-Oriented Programming (OOP) hughaguilar96@gmail.com - 2015-03-16 10:35 -0700
                Re: Object-Oriented Programming (OOP) Melzzzzz <mel@zzzzz.com> - 2015-03-16 19:57 +0100

Page 2 of 2 — ← Prev page 1 [2]

#37185

On 3/11/15 2:57 PM, Paul E Bennett wrote:
> Steve Graham wrote:
>
>> Over the years, I've seen posts here in c.l.f. denying the need for OOP.
>> And personally I have rarely used it in almost 35 years of programming.
>>
>> Interesting to hear criticism of the concept from leaders in the CS field:
>>
>> http://www.quora.com/Was-object-oriented-programming-a-failure/answer/Michael-O-Church?share=1
>>
>> Steve
>
> It is sometimes hard to figure out where the boundaries are between the
> different proclaimed styles of programming. My view might be down to the
> deeply embedded environments I deal with (where Finite State Machines and
> Component Oriented Design seem to work well). I probably use a number of
> styles without really thinking about which one I am using. So, my question
> is "why are we so concerned?"
>

We get concerned when it appears that we're being pressured to use OOP 
where it isn't indicated. In the late 90's when we were involved in 
"smart card" programming, there was great pressure to use Java. At one 
point we participated in a comparison, in which the same card program 
was written in Forth, C, and Java (written by different programmers 
experienced in each). Size was a major issue, since the processors used 
in the cards were very tight on memory.

Naturally the Forth program was the smallest. Surprisingly, it was also 
slightly faster than the C version, which was twice the size. The Java 
version was very significantly larger than the others, and very 
significantly slower as well. Looking at the code, it was clear that 
Java was really being twisted to perform the kinds of things the app 
required, as the app was simple and thoroughly procedural.

Of course, the result was that the companies managed to develop bigger 
and more expensive card processors and used Java.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#37190

On Thursday, 12 March 2015 04:31:13 UTC, Elizabeth D. Rather  wrote:
> On 3/11/15 2:57 PM, Paul E Bennett wrote:
> > Steve Graham wrote:
> >
> >> Over the years, I've seen posts here in c.l.f. denying the need for OOP.
> >> And personally I have rarely used it in almost 35 years of programming.
> >>
> >> Interesting to hear criticism of the concept from leaders in the CS field:
> >>
> >> http://www.quora.com/Was-object-oriented-programming-a-failure/answer/Michael-O-Church?share=1
> >>
> >> Steve
> >
> > It is sometimes hard to figure out where the boundaries are between the
> > different proclaimed styles of programming. My view might be down to the
> > deeply embedded environments I deal with (where Finite State Machines and
> > Component Oriented Design seem to work well). I probably use a number of
> > styles without really thinking about which one I am using. So, my question
> > is "why are we so concerned?"
> >
> 
> We get concerned when it appears that we're being pressured to use OOP 
> where it isn't indicated. In the late 90's when we were involved in 
> "smart card" programming, there was great pressure to use Java. At one 
> point we participated in a comparison, in which the same card program 
> was written in Forth, C, and Java (written by different programmers 
> experienced in each). Size was a major issue, since the processors used 
> in the cards were very tight on memory.
> 
> Naturally the Forth program was the smallest. Surprisingly, it was also 
> slightly faster than the C version, which was twice the size. The Java 
> version was very significantly larger than the others, and very 
> significantly slower as well. Looking at the code, it was clear that 
> Java was really being twisted to perform the kinds of things the app 
> required, as the app was simple and thoroughly procedural.
> 
> Of course, the result was that the companies managed to develop bigger 
> and more expensive card processors and used Java.
> 
> Cheers,
> Elizabeth
> 

I've had a similar experience with Java. I actually quite like Java,
when it's being used as the right tool for the job. I recently (2013)
had to write an assembler for a Forth processor (just a VHDL 
experimental decvice). There was an interest expressed to have the
assembler work on any platform, so Java was selected. To be honest,
it was a bit of a mountain to climb to get an object oriented language
to fit around a decidedly procedural problem. You're forced to make
objects. The easiest solution is to make one giant object and just use
methods internally all within the same class. I didn't use that approach
but I probably should have.

[toc] | [prev] | [next] | [standalone]

#37196

Well, I somehow disagree with some comments. OOP is sometimes described as an opposite to procedural programming, as complex, as a tool to manage complexity, ...

In my opinion, programming is all about naming things. That's why I love Forth : you have to design your words (decomposition) and to find the right name for the words you write. If you can't find a good name, well, perhap's something is wrong with your design.

I don't talk about objects, classes, decomposing the world, all this stuff that comes with OOP ... I just talk about naming words.

OOP, with polymorphism, helps here : if you think that two words should have the same name, and even if implementation is different, imho, you should be allowed to give them the same name. For instance, if I need various additions, I would like to call them "+" and not +, f+, l+, thing+, ... Like in mathematics, when you know what kind of object you are dealing with, you know that + will refere to "+ for reals", "+ for matrix", ... without, most of the time, the need to specify it. By the way, that's why I decided to write Oforth language : I wanted to keep Forth mecanisms and have polymorphism. 

For instance, if == is defined as the equal operator (same value, not same reference) and if I write this sort of code into a word : 
1 2 ==
1.3 1.3 ==
1 1.2 ==
[ 1, 2, 3 ] [ 1, 2, 3 ] ==
[ [ $a, 12 ], [ $b, 13 ] ] [ [ $a, 13 ], [ $b, 12 ] ] ==
'a' 'b' ==
"abcd" "abcef" ==
5 "abcde" size ==
5 [ 1, 2, 3, 4 ] size ==

Is it procedural ? For me, yes it is.
Is it OOP ? Yes it is. 
Is it increasing complexity ? I don't think so.

Is it managing complexity ? Certainly, this code would not be more complex if we used f== or s== or l==. You just need to know about 4 words instead of one, but that's not a big deal. One "concern" (well, at least mine) is that I think that == is unique (with multiple implementations if needed) and that there is no multiple equal operators. Just my opinion, of course...

Imho, you should be able to write procedural code and you should be able to name your words the exact way you think they should be named. OOP certainly helps to do this, not as a tool, but as a way to design words that need polymorphism.

Cheers,
Franck

[toc] | [prev] | [next] | [standalone]

#37302

franck.bensusan@gmail.com wrote:

> For instance, if == is defined as the equal operator (same value, not same reference) and if I write this sort of code into a word : 
> 1 2 ==
> 1.3 1.3 ==
> 1 1.2 ==
> [ 1, 2, 3 ] [ 1, 2, 3 ] ==
> [ [ $a, 12 ], [ $b, 13 ] ] [ [ $a, 13 ], [ $b, 12 ] ] ==
> 'a' 'b' ==
> "abcd" "abcef" ==
> 5 "abcde" size ==
> 5 [ 1, 2, 3, 4 ] size ==

What dialect of Forth is this?

It looks much higher-level than ANS Forth.

[toc] | [prev] | [next] | [standalone]

#37303

Le lundi 16 mars 2015 19:11:11 UTC+1, WJ a écrit :
> > For instance, if == is defined as the equal operator (same value, not same reference) and if I write this sort of code into a word : 
> > 1 2 ==
> > 1.3 1.3 ==
> > 1 1.2 ==
> > [ 1, 2, 3 ] [ 1, 2, 3 ] ==
> > [ [ $a, 12 ], [ $b, 13 ] ] [ [ $a, 13 ], [ $b, 12 ] ] ==
> > 'a' 'b' ==
> > "abcd" "abcef" ==
> > 5 "abcde" size ==
> > 5 [ 1, 2, 3, 4 ] size ==
> 
> What dialect of Forth is this?
> 
> It looks much higher-level than ANS Forth.

This is Oforth (for OOP + Forth)

Objective is to keep Forth mecanisms (when possible) while adding desktop/server features (OOP, GC, functional programming, multi-tasking, ...) as built-in features into the compiler/interpreter.

You can find Oforth examples on rosetta code.

[toc] | [prev] | [next] | [standalone]

#37310

On 3/16/15 2:39 PM, franck.bensusan@gmail.com wrote:

> This is Oforth (for OOP + Forth)
>
> Objective is to keep Forth mecanisms (when possible) while adding desktop/server features (OOP, GC, functional programming, multi-tasking, ...) as built-in features into the compiler/interpreter.

Do you have a version that runs on OS X native (no Windows emulator 
required)?

-Doug

[toc] | [prev] | [next] | [standalone]

#37315

> Do you have a version that runs on OS X native (no Windows emulator 
> required)?
> 
> -Doug

No yet (but planned). Windows version should run well on WINE (I had a return it runs well on WINE under Linux, no reason it should not run well under Mac OS X).

[toc] | [prev] | [next] | [standalone]

#37314

franck.bensusan@gmail.com wrote:

> Le lundi 16 mars 2015 19:11:11 UTC+1, WJ a écrit :
> > > For instance, if == is defined as the equal operator (same value, not same reference) and if I write this sort of code into a word : 
> > > 1 2 ==
> > > 1.3 1.3 ==
> > > 1 1.2 ==
> > > [ 1, 2, 3 ] [ 1, 2, 3 ] ==
> > > [ [ $a, 12 ], [ $b, 13 ] ] [ [ $a, 13 ], [ $b, 12 ] ] ==
> > > 'a' 'b' ==
> > > "abcd" "abcef" ==
> > > 5 "abcde" size ==
> > > 5 [ 1, 2, 3, 4 ] size ==
> > 
> > What dialect of Forth is this?
> > 
> > It looks much higher-level than ANS Forth.
> 
> This is Oforth (for OOP + Forth)
> 
> Objective is to keep Forth mecanisms (when possible) while
> adding desktop/server features (OOP, GC, functional
> programming, multi-tasking, ...) as built-in features into
> the compiler/interpreter.
>
> You can find Oforth examples on rosetta code.

Does it work under Windows XP?

I downloaded the 3 latest versions from here:
http://www.oforth.com/download

The only version that worked for me under Windows XP
was V0.9.15.

I had to set the path to
set OFORTH_PATH=/C/bin/oforth
  instead of
set OFORTH_PATH=C:/bin/oforth

Integers weren't handled correctly:

>99 .s
[1] (Integer) 18508057755517027

[toc] | [prev] | [next] | [standalone]

#37316

> Integers weren't handled correctly:
> 
> >99 .s
> [1] (Integer) 18508057755517027

send you a pm. Not sure this is the subject of this topic...

[toc] | [prev] | [next] | [standalone]

#37227

I noticed that the Rosetta code site was either missing Forth OO code or 
the examples were using non-ANS implementations.  I have filled out the 
following with ANS compatible code:

http://rosettacode.org/wiki/Classes#Forth
http://rosettacode.org/wiki/Polymorphism#Forth
http://rosettacode.org/wiki/Inheritance/Single#Forth
http://rosettacode.org/wiki/Inheritance/Multiple#Forth
http://rosettacode.org/wiki/Break_OO_privacy#Forth
http://rosettacode.org/wiki/Polymorphic_copy#Forth
http://rosettacode.org/wiki/Flatten_a_list#Forth (doesn't need to be OO, 
but I'd already written the solution and there was no Forth entry, flack 
jacket on)

-Doug

[toc] | [prev] | [next] | [standalone]

#37259

On Friday, March 13, 2015 at 8:52:38 AM UTC-7, Doug Hoffman wrote:
> I noticed that the Rosetta code site was either missing Forth OO code or 
> the examples were using non-ANS implementations.  I have filled out the 
> following with ANS compatible code:
> 
> http://rosettacode.org/wiki/Classes#Forth
> http://rosettacode.org/wiki/Polymorphism#Forth
> http://rosettacode.org/wiki/Inheritance/Single#Forth
> http://rosettacode.org/wiki/Inheritance/Multiple#Forth
> http://rosettacode.org/wiki/Break_OO_privacy#Forth
> http://rosettacode.org/wiki/Polymorphic_copy#Forth

I use single-inheritance in my novice-package quite a lot. With ALLOCATION available I can clone any struct (ALLOCATION provides the size of the struct, so that much memory can be copied).

The major difficulty is that some of the fields may be pointers to other structs. When cloning a struct of unknown type, there is no way to distinguish between an integer and a pointer, so a recursive general-purpose clone function can't be written. The solution is to make virtual functions in your class that contain a vector to a clone function for that type of struct, so the struct can clone itself --- but this is a hassle --- this adds a lot of code to the class.

My novice-package doesn't provide polymorphism --- field names can clash from one class to another.

> http://rosettacode.org/wiki/Flatten_a_list#Forth (doesn't need to be OO, 
> but I'd already written the solution and there was no Forth entry, flack 
> jacket on)

I looked into writing this one myself, but gave up on it. Once again, the problem with my novice package is that I can't tell the difference between an integer and a pointer, so in that list I can't distinguish between a node that contains an integer and a node that contains a pointer to a list that contains integers and/or pointers to sub-lists.

The solution is to have a tag in each node that tells what type it is. I'm not familiar with that package you are using, but this seems to be what you have, as you have an [IS-A] function that is figuring out the type of the object at run-time. Tagged data and run-time type determination is grossly inefficient, and I think it has no place in Forth that is a low-level language.

If I were to use tagged data and OOP, it would be in Scheme or some other scripting language --- I don't think this is a good idea in Forth --- I am mostly only interested in Forth for use in micro-controllers, not desktop-computers.

[toc] | [prev] | [next] | [standalone]

#37271

On 3/14/15 4:52 PM, hughaguilar96@gmail.com wrote:
> On Friday, March 13, 2015 at 8:52:38 AM UTC-7, Doug Hoffman wrote:
>> I noticed that the Rosetta code site was either missing Forth OO
>> code or the examples were using non-ANS implementations.  I have
>> filled out the following with ANS compatible code:
>>
>> http://rosettacode.org/wiki/Classes#Forth
>> http://rosettacode.org/wiki/Polymorphism#Forth
>> http://rosettacode.org/wiki/Inheritance/Single#Forth
>> http://rosettacode.org/wiki/Inheritance/Multiple#Forth
>> http://rosettacode.org/wiki/Break_OO_privacy#Forth
>> http://rosettacode.org/wiki/Polymorphic_copy#Forth
>
> I use single-inheritance in my novice-package quite a lot. With
> ALLOCATION available I can clone any struct (ALLOCATION provides the
> size of the struct, so that much memory can be copied).
>
> The major difficulty is that some of the fields may be pointers to
> other structs. When cloning a struct of unknown type, there is no way
> to distinguish between an integer and a pointer, so a recursive
> general-purpose clone function can't be written. The solution is to
> make virtual functions in your class that contain a vector to a clone
> function for that type of struct, so the struct can clone itself ---
> but this is a hassle --- this adds a lot of code to the class.

Same problem with the FMS OO extension.  Object cloning, if needed, 
usually must be customized for the class.  The code needed for the 
Rosetta Polymorphic_copy problem was fairly simple.

> My novice-package doesn't provide polymorphism --- field names can
> clash from one class to another.

Many OO packages, including FMS, use wordlists for data field names so 
there are no clashes there.  In addition the action words, messages, are 
polymorphic as is the case with most OO.

>> http://rosettacode.org/wiki/Flatten_a_list#Forth (doesn't need to
>> be OO, but I'd already written the solution and there was no Forth
>> entry, flack jacket on)
>
> I looked into writing this one myself, but gave up on it. Once again,
> the problem with my novice package is that I can't tell the
> difference between an integer and a pointer, so in that list I can't
> distinguish between a node that contains an integer and a node that
> contains a pointer to a list that contains integers and/or pointers
> to sub-lists.
>
> The solution is to have a tag in each node that tells what type it
> is. I'm not familiar with that package you are using, but this seems
> to be what you have, as you have an [IS-A] function that is figuring
> out the type of the object at run-time.

The [IS-A] introspection is a simple function and probably would be in 
any OO package since each object must ultimately know its class in order 
to respond to messages.  The tagging was already there.

> Tagged data and run-time type
> determination is grossly inefficient, and I think it has no place in
> Forth that is a low-level language.

There was no Forth solution to that problem until now.  Not saying there 
couldn't have been.

> If I were to use tagged data and OOP, it would be in Scheme or some
> other scripting language --- I don't think this is a good idea in
> Forth --- I am mostly only interested in Forth for use in
> micro-controllers, not desktop-computers.

The FMS OO package (single inheritance, without the *instructional 
example* class library) compiles to 7820 bytes on SwiftForth.  Doesn't 
seem like a lot.  But I've never done embedded work and wrote FMS for 
desktop computer use.

Once again I wonder if this newsgroup should be split into two: one for 
embedded topics and the other for large resource (desktop) topics.

-Doug

[toc] | [prev] | [next] | [standalone]

#37277

On Sunday, March 15, 2015 at 4:17:19 AM UTC-7, Doug Hoffman wrote:
> On 3/14/15 4:52 PM, hughaguilar96@gmail.com wrote:
> > My novice-package doesn't provide polymorphism --- field names can
> > clash from one class to another.
> 
> Many OO packages, including FMS, use wordlists for data field names so 
> there are no clashes there.  In addition the action words, messages, are 
> polymorphic as is the case with most OO.

Pascal had its WITH command that specified the object, and because Pascal is typed this also specified the object's class. Presumably you are doing something similar, except that you have to specify the class explicitly.

This is a bad idea. If you do this, you can only access one object at a time. To work with more than one object, you have to continually use WITH to specify the which one you want to use. This was a big reason why Pascal source-code tended to be grossly bloated and unreadable --- this is not a good way for Forth to go.

Before you get too enthusiastic about adding WITH etc. to Forth, you should ask yourself why Delphi/Kylix is dead, despite having a big company like Borland pushing it --- maybe because this stuff is a bad idea and everybody hated it --- could that be the reason?

> > The solution is to have a tag in each node that tells what type it
> > is. I'm not familiar with that package you are using, but this seems
> > to be what you have, as you have an [IS-A] function that is figuring
> > out the type of the object at run-time.
> 
> The [IS-A] introspection is a simple function and probably would be in 
> any OO package since each object must ultimately know its class in order 
> to respond to messages.  The tagging was already there.

The tagging was not already there --- Forth doesn't normally have tagged data --- this is inefficiency added by the OO package.

I have inheritance in my novice package, but I don't have tags and I don't have any of this inefficiency.

> Once again I wonder if this newsgroup should be split into two: one for 
> embedded topics and the other for large resource (desktop) topics.

It is not the newsgroup that should be split in two --- it is the language.

I have said repeatedly that there should be two versions of Forth, one for desktop-computers (only 64-bit supported) and one for micro-controllers --- trying to make a single language work for both, as done in ANS-Forth and now Forth-200x, is a terrible idea --- rather than be the best of both worlds, it will be the worst of both worlds.

[toc] | [prev] | [next] | [standalone]

#37284

On 3/15/15 9:16 PM, hughaguilar96@gmail.com wrote:
> On Sunday, March 15, 2015 at 4:17:19 AM UTC-7, Doug Hoffman wrote:
>> On 3/14/15 4:52 PM, hughaguilar96@gmail.com wrote:
>>> My novice-package doesn't provide polymorphism --- field names
>>> can clash from one class to another.
>>
>> Many OO packages, including FMS, use wordlists for data field names
>> so there are no clashes there.  In addition the action words,
>> messages, are polymorphic as is the case with most OO.
>
> Pascal had its WITH command that specified the object, and because
> Pascal is typed this also specified the object's class. Presumably
> you are doing something similar, except that you have to specify the
> class explicitly.
>
> This is a bad idea. If you do this, you can only access one object at
> a time. To work with more than one object, you have to continually
> use WITH to specify the which one you want to use.

I agree that is a bad idea.  FMS doesn't work that way (nor do several 
other Forth OO extensions).  For example if print were a message and 
point and circle were class names (see Rosetta problem 
http://rosettacode.org/wiki/Polymorphism#Forth ):

0 value x
point p1 p1 to x  ( or dict> point to x )
x print
circle c3 c3 to x ( or heap> circle to x )
x print

*Any* object can be stored in x or wherever (stack, variable, local, 
return stack, anyplace).  Even future objects whose classes have yet to 
be written.  As long as the class of object is designed to respond to 
the print message it will do the right thing.  If not it aborts with 
"message not understood".  Declaring class type is never required for 
messaging.

> This was a big
> reason why Pascal source-code tended to be grossly bloated and
> unreadable --- this is not a good way for Forth to go.

>>> The solution is to have a tag in each node that tells what type
>>> it is. I'm not familiar with that package you are using, but this
>>> seems to be what you have, as you have an [IS-A] function that is
>>> figuring out the type of the object at run-time.
>>
>> The [IS-A] introspection is a simple function and probably would be
>> in any OO package since each object must ultimately know its class
>> in order to respond to messages.  The tagging was already there.
>
> The tagging was not already there --- Forth doesn't normally have
> tagged data --- this is inefficiency added by the OO package.

I rarely use IS-A, but when I need it it's there.

> I have inheritance in my novice package, but I don't have tags and I
> don't have any of this inefficiency.

You are right that a Forth OO package carries some overhead due to 
message sending.  But this overhead can be small.  Anton Ertl wrote a 
2012 EuroForth paper that nicely covers the topic: "Methods in objects2: 
Duck Typing and Performance".

If OO is not appropriate for the problem, don't use it (stating the 
obvious, I know). Further, *if* you want OO but the execution time is an 
issue, rare in my work, don't use it.

>> Once again I wonder if this newsgroup should be split into two: one
>> for embedded topics and the other for large resource (desktop)
>> topics.
>
> It is not the newsgroup that should be split in two --- it is the
> language.

Perhaps so.  I've never done embedded work so I don't feel qualified to 
comment.

-Doug

[toc] | [prev] | [next] | [standalone]

#37286

Adding to my reply to the hughaguilar96@gmail.com post on 3/15/15 9:16 PM:

On 3/16/15 5:50 AM, Doug Hoffman wrote:
> If OO is not appropriate for the problem, don't use it (stating the
> obvious, I know). Further, *if* you want OO but the execution time is
> an issue, rare in my work, don't use it.

That statement needs qualification because defining OO with precision is
difficult if even possible.  Above I am referring specifically to FMS.
There appears to be no universally accepted OO definition in any
language.  Certainly some OO concepts already exist in Forth and/or can
be used in Forth without adding an extension like FMS.

Some would say that, for example, FMS is an incomplete way to program
with objects because there is no automatic garbage collection.  With
that context/definition they would be right.  Others would say that
unless everything is an object you are not programming in OOP.  Again,
that would also be a correct statement if that is one's
requirement/definition.  My package uses neither of these features
because they don't fit my programming style.  While I wouldn't turn down
automatic garbage collection if it could be had for little cost/effort,
I find that freeing up allocated objects manually works well enough for
my problem domain.

The meta object protocol is yet another possible way to program with
objects, but I have yet to see (an ANS) Forth package for evaluation so
I don't know much about that except what I read.  Looks a bit complex
for my purposes.

You say that your novice package uses some OO techniques and you are right.

-Doug

[toc] | [prev] | [next] | [standalone]

#37299

On Monday, March 16, 2015 at 5:54:42 AM UTC-7, Doug Hoffman wrote:
> Adding to my reply to the hughaguilar96@gmail.com post on 3/15/15 9:16 PM:
> 
> On 3/16/15 5:50 AM, Doug Hoffman wrote:
> > If OO is not appropriate for the problem, don't use it (stating the
> > obvious, I know). Further, *if* you want OO but the execution time is
> > an issue, rare in my work, don't use it.
> 
> That statement needs qualification because defining OO with precision is
> difficult if even possible.  Above I am referring specifically to FMS.
> There appears to be no universally accepted OO definition in any
> language.  Certainly some OO concepts already exist in Forth and/or can
> be used in Forth without adding an extension like FMS.
> 
> Some would say that, for example, FMS is an incomplete way to program
> with objects because there is no automatic garbage collection.  With
> that context/definition they would be right.  Others would say that
> unless everything is an object you are not programming in OOP.  Again,
> that would also be a correct statement if that is one's
> requirement/definition.  My package uses neither of these features
> because they don't fit my programming style.  While I wouldn't turn down
> automatic garbage collection if it could be had for little cost/effort,
> I find that freeing up allocated objects manually works well enough for
> my problem domain.
> 
> The meta object protocol is yet another possible way to program with
> objects, but I have yet to see (an ANS) Forth package for evaluation so
> I don't know much about that except what I read.  Looks a bit complex
> for my purposes.
> 
> You say that your novice package uses some OO techniques and you are right.
> 
> -Doug

I don't have anything against people using OOP --- just so long as the language doesn't *require* OOP and impose OOP-related inefficiency even when the program is purely procedural (like in Ruby where everything is an object).

Note that I figured out a way in my language for EXECUTE to be exactly the same speed for calling a colon word as it has always been --- adding quotations (anonymous nested functions) doesn't drag down the efficiency for those users who don't want to use them. Quotations have nothing to do with OOP --- I'm just pointing out that new features shouldn't affect old features --- I do require the xt to be a double-cell though, which is incompatible with ANS-Forth.

[toc] | [prev] | [next] | [standalone]

#37294

> Before you get too enthusiastic about adding WITH etc. to Forth, you should ask yourself why Delphi/Kylix is dead, despite having a big company like Borland pushing it --- maybe because this stuff is a bad idea and everybody hated it --- could that be the reason?

If you look at the Embarcadero website, it looks like Delphi is alive and kicking.
Kylix on the other hand appears to be abandoned.

Just thought you might like to know that.

[toc] | [prev] | [next] | [standalone]

#37300

On Monday, March 16, 2015 at 9:02:55 AM UTC-7, novembe...@gmail.com wrote:
> > Before you get too enthusiastic about adding WITH etc. to Forth, you should ask yourself why Delphi/Kylix is dead, despite having a big company like Borland pushing it --- maybe because this stuff is a bad idea and everybody hated it --- could that be the reason?
> 
> If you look at the Embarcadero website, it looks like Delphi is alive and kicking.
> Kylix on the other hand appears to be abandoned.
> 
> Just thought you might like to know that.

Thanks for telling me about that --- I had never heard of Embarcadero before --- apparently they bought Delphi from Borland.

There is also the humorously named Lazerus Pascal.

A lot of people liked Delphi, so I'm glad they can continue to do what they enjoy doing. :-)

Kylix was likely abandoned not because it is Pascal, but because it is for writing commercial programs for Linux --- this goes against the GNU spirit, in which programmers have a masochistic desire to work for free and give their source-code to the PRC.

[toc] | [prev] | [next] | [standalone]

#37304

On Mon, 16 Mar 2015 10:35:40 -0700 (PDT)
hughaguilar96@gmail.com wrote:

> On Monday, March 16, 2015 at 9:02:55 AM UTC-7, novembe...@gmail.com
> wrote:
> > > Before you get too enthusiastic about adding WITH etc. to Forth,
> > > you should ask yourself why Delphi/Kylix is dead, despite having
> > > a big company like Borland pushing it --- maybe because this
> > > stuff is a bad idea and everybody hated it --- could that be the
> > > reason?
> > 
> > If you look at the Embarcadero website, it looks like Delphi is
> > alive and kicking. Kylix on the other hand appears to be abandoned.
> > 
> > Just thought you might like to know that.
> 
> Thanks for telling me about that --- I had never heard of Embarcadero
> before --- apparently they bought Delphi from Borland.
> 
> There is also the humorously named Lazerus Pascal.

Lazarus is IDE for Free Pascal. Live and kicking, as well.


> 
> A lot of people liked Delphi, so I'm glad they can continue to do
> what they enjoy doing. :-)
> 
> Kylix was likely abandoned not because it is Pascal, but because it
> is for writing commercial programs for Linux --- this goes against
> the GNU spirit, in which programmers have a masochistic desire to
> work for free and give their source-code to the PRC.

Nope. Embarcadero announced that it will support Linux as target
platform, but product will not have Kylix name rather it will be part
of standard package. 

Only thing that I see is missing is that Free Pascal does not supports
64 bit ;(
But Lazarus is RAD tool, like Delphi.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web