Is Spin Really OO?
soshimo
Posts: 215
I'm just learning spin and I really like that it's very readable yet seems very close "to the metal" as it were. Not something you see much in higher level languages which tend to abstract a lot of basic functionality. My primary occupation is an embedded systems programmer so I'm always looking for ways to make life easier when talking to hardware and spin is looking more and more like that solution. Here is my question, not being too versed in spin yet (just started learning a week ago), what kind of OOP concepts does spin actually support? I'll go ahead and list some of the more common ones and the ones that I feel make an OO language strong.
Objects - A pattern (exemplar) of a class.
Methods - An object's abilities. In language, methods (sometimes referred to as "functions") are verbs.
Message passing - The process by which an object sends data to another object or asks the other object to invoke a method. Also known to some programming languages as interfacing.
Inheritance - 'Subclasses' are more specialized versions of a class, which inherit attributes and behaviors from their parent classes, and can introduce their own.
Abstraction - Abstraction is simplifying complex reality by modelling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem.
Encapsulation - Encapsulation conceals the functional details of a class from objects that send messages to it.
Polymorphism - Polymorphism allows the programmer to treat derived class members just like their parent class' members. More precisely, Polymorphism in object-oriented programming is the ability of objects belonging to different data types to respond to method calls of methods of the same name, each one according to an appropriate type-specific behavior.
Decoupling - allows for the separation of object interactions from classes and inheritance into distinct layers of abstraction.
I realize that Objects, Methods and somewhat Encapsulation are definitely implemented but I don't see a mechanism for polymorphism or inheritance. To me it's a lot like how Visual Basic (pre .Net) was 'OO'. It was 'kinda' OO, but not really. Much like you can do OO in C, you just have to be much more cognitive of what you are doing and you have to roll your own vtables and such (for virtual functions to support polymorphism). Where or how does spin implement any of the other OO principles that I'm familiar with? TIA.
Objects - A pattern (exemplar) of a class.
Methods - An object's abilities. In language, methods (sometimes referred to as "functions") are verbs.
Message passing - The process by which an object sends data to another object or asks the other object to invoke a method. Also known to some programming languages as interfacing.
Inheritance - 'Subclasses' are more specialized versions of a class, which inherit attributes and behaviors from their parent classes, and can introduce their own.
Abstraction - Abstraction is simplifying complex reality by modelling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem.
Encapsulation - Encapsulation conceals the functional details of a class from objects that send messages to it.
Polymorphism - Polymorphism allows the programmer to treat derived class members just like their parent class' members. More precisely, Polymorphism in object-oriented programming is the ability of objects belonging to different data types to respond to method calls of methods of the same name, each one according to an appropriate type-specific behavior.
Decoupling - allows for the separation of object interactions from classes and inheritance into distinct layers of abstraction.
I realize that Objects, Methods and somewhat Encapsulation are definitely implemented but I don't see a mechanism for polymorphism or inheritance. To me it's a lot like how Visual Basic (pre .Net) was 'OO'. It was 'kinda' OO, but not really. Much like you can do OO in C, you just have to be much more cognitive of what you are doing and you have to roll your own vtables and such (for virtual functions to support polymorphism). Where or how does spin implement any of the other OO principles that I'm familiar with? TIA.
Comments
IMHO, "objects" in Spin are more like included library functions.
Post Edited (Rayman) : 12/19/2008 2:10:33 PM GMT
All it has is the ability to treat each file as an independent package of data + methods; in
some ways this could be thought as "ultra-light" OO, but lack of inheritance really makes
use of the word OO a bit of an overreach.
But then again, for embedded development, what Spin provides is amply sufficient for most
practical uses.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
Jo
SPIN borrows a few concepts from OO, but it's not really OO in my opinion.· There are many fundamental concepts of OO (such as inheritance) that SPIN does not support.
The following is a discription of the level of support in SPIN for the various concepts.
Objects - a SPIN object is not really the same as an OO object.· In OO, and object is an instantiation of a class and can be instantiated dynamically at run time.· In SPIN, an object is a piece of code that is packaged togther with methods and encapsulation.··Objects·in SPIN are static and·each instance is specified at compile time.·
Encapsulation - this feature is supported·in SPIN.· It makes code re-use easy and allows the Object Exchange to be so useful.
Methods - also supported
Message Passing - this is really just another name for methods on objects.· One thing SPIN does not support is references to methods.
Inheritance - not supported.
Abstraction - in the inheritance sense not supported.· However, you can abstract away a lot of hardware complexity by encapsulating it in an "object".
Polymorphism - not really suppored because this concept builds on inheritance
Decoupling·- as it relates to inheritance, not supported.
The OO-type features SPIN does support are mainly for the facilitation of code re-use·and better code organization.· This is a microcontroller with 32K of RAM after all, and many of the other OO concepts would be overkill.·
Regards,
Ken
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
I may be missing some feature of Spin that I should have seen, but I would disagree that it doesn't need structures. There are two important features of C structures : the ability to declare the layout separately from the data instance, and respecting the declaration order of the members.
Neither of these exist in Spin, even though I'd say that defining a data structure is even more fundamental to OO than objects and methods. Therefore, you cannot declare a structure and have methods share it : every method has to communicate through individual objects or arrays and pointers become far less useful than they might have been.
The regrouping of variables into bytes, words and longs is also a mistake IMHO : it may help with alignment inefficiencies but it makes it impossible to use the location in memory for anything except arrays of the same type : you can't use it to construct a message to an external device because it mixes all the elements up.
-adrian
Keep in mind that SPIN is an interpreted language, and that interpreter fits into a space of 512 longs. There were some compromises made to achieve this.
Perhaps if someone wants to create a C++, C#, or other high level language compiler making use of the large memory model, then some of these items can be realized.
That said, it would be nice to be able to construct more meaningful data structures in SPIN than arrays of just one type.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Post Edited (Paul Baker) : 12/19/2008 6:36:22 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
I don't see any need to change the interpreter which has little to do with OO - it's mostly there to provide high code density (so the hub memory fetch time is worthwhile) and to keep the silicon complexity down.
-adrian
You may not appreciate just how tight the Spin interpreter is and the Prop II is not going to change that. There will be a little savings from being able to use some of the new instructions, but I suspect that will be minimal and will be needed just to include access in the interpretive code to the new instructions.
Parallax is certainly not going to expend the effort to produce any kind of C (or C++ or C#) compiler for the Propeller, particularly since there is a 3rd party C compiler already available. Whether there's enough interest on the part of the user community to adapt perhaps the GCC toolchain for a LMM (large memory model) interpreter for C++, we'll just have to wait and see once the Prop II is available. You're talking about a major effort on the part of a few individuals, but magic has happened already with the several Spin compilers now available. Keep in mind that there's a lot of overhead involved in a C++ implementation including dynamic memory management, not really appropriate for a microcontroller other than as a demonstration platform.
Thanks for all the great replies. I agree that implementing most of the concepts of an OOL would be overkill for a ucontroller but I have read over and over that Spin is an Object Oriented language which is why I asked this question. I'm new to learning Spin but I still haven't seen these constructs in the language so was thinking that I may be missing something. I am also aware that Spin is very close to the hardware but so is C (if you've ever written an ASIC drivers you will know what I'm talking about). Unfortunately the constructs of an OOL tend to bloat and increase the runtime memory footprint so the power is lost on smaller memory models (which is why most ASIC drivers are written in C and/or assembler).
-Soshimo
Welcome aboard and happy Spinning!· There are many talents in this forum and many people that are more than willing to lend a hand.· Feel free to ask any questions that you might have as you get started with your new Propeller chip.
·
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
What's the board in your user picture? Looks interesting and kind of old school.
Yeah, I like the Prop for exactly these reasons. It's easy to look at what it doesn't have. Getting your brain wrapped around what it does have has been a very fun and productive ride. I had been out of this scene since the late 80's, and it was 8 bit computers then, and I hooked my prop up and got some stuff done in one evening. What a fun rush! This analogy might not make any sense, but the Prop feels a lot like the PERL of micros. For sysadmin and systems engineering PERL is that magic glue that can make great stuff happen quick. Propeller feels the same!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
with programming experience in PERL and various BASIC dialects I appreciate
the fact that it isn't as restrictive in the way that truly OO languages are.
Of course this can contribute to sloppy code, but the Propeller is fast enough
to be forgiving even when I have created monsters which could have been done
in a few lines.
I'm with potatohead that the Propeller feels very 80's to me. My kids tell me
that I'm trapped in the 80's.. What do you mean they don't play music videos
on MTV anymore?? [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
You're probably right that I don't appreciate how tight the spin interpreter is, though I have had the ?enjoyment? of working on C and assembler projects where every new feature needed half-a-dozen other parts to be recoded to make enough space, so I'm aware of the tricks that have to be pulled to make things fit. And I'm not an OO person - I'm most comfortable in straight C, so I don't care much about the bigger OO stuff like garbage collectors.
But I do feel some of those features are not runtime stuff and so shouldn't impact the interpreter, however restricted it is : structures, for instance, once in memory are no different from a list of variables : it's the compiler that keeps track of instance and element addresses and provides the bytecode with appropriate offset values. Pointers to structures have very similar runtime needs to array arithmetic, which is already supported.
Similarly inheritance - although I don't miss it, it's all about naming and linkage, not calling conventions or other runtime needs.
-adrian
You're absolutely right that a lot of the OO features can be done completely in the compiler including structures and pointers to structures although structures larger than 4 bytes would create some overhead unexpected from the ease of writing code using them since block copies and block compares would have to be used and multiplication (by a constant) would need to be used for subscripting, not always just shifts.
Purely static inheritance could be done although there's no provision for multi-level object calls. There would need to be dummy methods added to any object that does "pass through" to a lower level. Theoretically, these could update their method pointer table to point directly to the lower level method, but I'm not sure that would be a worthwhile tradeoff for speed vs. code space.
Post Edited (soshimo) : 12/20/2008 10:37:01 PM GMT
But, Inheritance and several other fun things can be added to spin with only a pre-compiler. The spin byte-code and object structure is actually amazingly flexible. All the objects are relocatable and the VAR portions of objects are also. This actually makes inheritance fairly easy to implement. Objects in spin can also be instantiated at runtime if you are willing to play around with different pointers. Again, it just needs a pre-compiler to make it easy to use. Structures could also be added fairly easily with a pre-compiler if someone actually put in the time to do it.
However, each of these things starts making the whole spin language more complex which is probably why they were left out in the first place.