Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[SamuraiCrow]

One thing that I think may be safely avoided is pervasive OOP.  For the version 3 branch of AMOS, we should focus on making it easier to write extensions.  If possible, make AmosPro capable of compiling its own extensions from a compiler.  (I think the Amos compiler is a nearly lost cause on anything faster than a raw 68000 so it may need a new compiler altogether but this is another topic.)  I think prototype inheritance is good enough for JavaScript 1.x so it is good enough for the 3.x branch.

An extension can define the rest of the classical OOP structures as has been done with JavaScript and MooTools, Prototype.js and so on.  Also, it should be noted, that if we are going to make the 3.x branch AROS 68k specific, it may be able to use OOP.library from inside the AROS kernel.

[SamuraiCrow]

When I was thinking about the sorting algorithm problem, it occurred to me that my Java 1.4.x version of my iterative natural mergesort doesn't use generics.  If we're going to use OOP, we'll probably need to be able to support compile-time type checking to reduce the complexity at runtime.  I'll have to think about this some more but I think OOP is actually possible for Bank structures.  The catch is... do people want OOP in AmosPro?

[ebanite]

Yes, it'll be a big step for AmosPro, OOP can bring Amos in a new kind of dimension, otherwise AmosPro still a good Fast Basic but nothing else, OOP can make hard for newbe to understand the language, but in those days any moder language support OOP, not only it is cool, but it make programming more elegant, modern, portable, the source code can be easy to upgrade for any kind of projcet, and you can import code from other language in less pain...that can be a really new born for the amospro, but it need a radically change in everything, makeking the compiler hard to be made, and the only solution to make your app...no more interpretation of the source code due to complexity of OOP.

[SamuraiCrow]

Yes, it'll be a big step for AmosPro, OOP can bring Amos in a new kind of dimension, otherwise AmosPro still a good Fast Basic but nothing else, OOP can make hard for newbe to understand the language, but in those days any moder language support OOP, not only it is cool, but it make programming more elegant, modern, portable, the source code can be easy to upgrade for any kind of projcet, and you can import code from other language in less pain...that can be a really new born for the amospro, but it need a radically change in everything, makeking the compiler hard to be made, and the only solution to make your app...no more interpretation of the source code due to complexity of OOP.

Who said anything about giving up on interpreted Amos?  JavaScript is either interpreted or JIT compiled and it is object oriented... [emoji1]

Sent from my Prism II

[SamuraiCrow]

As I figure it, the crux of adding OOP to Amos is that we need an associative array data structure (aka hash table or dictionary or unordered-map or whatever else it can possibly be called in any other language).  Once we have that it will be a simple matter to declare a type name for each bank type as a BANK parent class.  This will replace the type header in the existing BANK structure with a pointer to a type definition structure including a prototype associative array that associates method names to the member functions in each bank and a second associative array of parent BANK formats to implement multiple inheritance.  The remaining 4 bytes of type header (since there were 8 ASCII characters in the old header format, I think) would be dedicated to OOP reflection; that is, a reverse lookup to find type names from their addresses.

The next stage would be to associate banks to a bank variable type in addition to the old integer-associated handles to banks.  In this way we could avoid bank swap in a lot of code and the old bank numbers will become simple defaults for the old bank-handling command formats.

Do these steps sound reasonable for a major upgrade release of AmosPro?

[ebanite]

Javascript is not a fast language, any mother solution recomplite it for best performace, like firefox, chrome ,IE and any web broswer do, if we need a script language, we have already many solution, but if we are speaking about fast code, compiling is the only avaible solution...

[Lonewolf10]

The remaining 4 bytes of type header (since there were 8 ASCII characters in the old header format, I think) would be dedicated to OOP reflection; that is, a reverse lookup to find type names from their addresses.

There were 8 bytes used for each bank name, but the header of each bank is longer than that. If I remember correctly, there are 4 bytes that represent the bank length and atleast 1 byte that has flags set depending on the type of bank and whether it should be saved with the program file or not. I also believe the header changes slightly with certain types of banks.
Either way, there are more than 8 bytes to play with

Do these steps sound reasonable for a major upgrade release of AmosPro?

Yes, I think they sound pretty reasonable. But you should be asking the person (people?!) that will code it

Javascript is not a fast language, any mother solution recomplite it for best performace, like firefox, chrome ,IE and any web broswer do, if we need a script language, we have already many solution, but if we are speaking about fast code, compiling is the only avaible solution...

I agree, compiled programs are the only way to go when distributing speedy software.

[SamuraiCrow]

The remaining 4 bytes of type header (since there were 8 ASCII characters in the old header format, I think) would be dedicated to OOP reflection; that is, a reverse lookup to find type names from their addresses.

There were 8 bytes used for each bank name, but the header of each bank is longer than that. If I remember correctly, there are 4 bytes that represent the bank length and atleast 1 byte that has flags set depending on the type of bank and whether it should be saved with the program file or not. I also believe the header changes slightly with certain types of banks.
Either way, there are more than 8 bytes to play with

Do these steps sound reasonable for a major upgrade release of AmosPro?

Yes, I think they sound pretty reasonable. But you should be asking the person (people?!) that will code it

Javascript is not a fast language, any mother solution recomplite it for best performace, like firefox, chrome ,IE and any web broswer do, if we need a script language, we have already many solution, but if we are speaking about fast code, compiling is the only avaible solution...

I agree, compiled programs are the only way to go when distributing speedy software.

re:bank headers
I meant that the bank name could be changed by substituting a property in the type definition.  The rest of the fields in the header should remain largely unchanged by OOP.

re:compilation
I see compilation as a final draft solution.  The interpreted code is a debugging tool.  A JIT compiler can fulfill a similar function.  After having dealt with compiler technology, I'd say the compiler should be a separate project and perhaps we should just export to PortablE or some other compiled OOP programming language for our compiler.

[bruceuncle]

All this chat does make me wonder why you're still calling it AMOS?

OOP is a language that fully implements the tenets of the Grady Booch treatise on Object Oriented Analysis and Design in the book of the same name.  Anything less results in something like VBA (rolls around on the floor laughing for a few minutes) which thinks that just calling something a Class is good enough and inheritance and polymorphism are for nerds.

Quotes from Grady Booch:

"Object-oriented programming is a method of implementation in which programs are organised as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."

"Polymorphism exists when the features of inheritance and dynamic binding interact.  It is perhaps the most powerful feature of object-oriented programming languages next to their support for abstraction, and it is what distinguishes object-oriented programming from more traditional programming with abstract data types."


Sorry to be boring about it, but what you're talking about is implementing an OOP on an Amiga.  Not an OOP implementation of AMOS.

I suppose you could envisage using the amos.library functions and data structures behind a façade, and coupling it up to an object broker and factory, and building up a language model from there.  I wouldn't think that amos.library would be all that suitable for such a project.  But that's my point.  Why call it AMOS at all?  By that stage, it would be so far removed from the existing AMOS Pro as to be almost unrecognisable anyway.

I would have thought a completely new look at the Amiga hardware (OCS, ECS and AGA) and developing an OOP from scratch would be easier and more rewarding.  There's probably a good case for using some of the abstractions already used in AMOS as they work so well (eg. the brilliant concept of using Banks as both temporary and persistent memory blocks).  And the Amiga libraries already have familiar abstractions (screen, window, gadget, sprite, etc.).  But the final language would not be all that familiar to an AMOS programmer as the whole paradigm would change from procedural/modular to OO.  I think you may also have difficulties in deciding on the most appropriate levels of abstraction.  (Many OO projects that I encountered in commercial life made the mistake of going to too lower a level of abstraction.)

I don't think that either approach would be easy.

Just chasing down and fixing AMOS Pro bugs, and slogging through correcting and revising the docs is taking up all the little (currently) spare time I have.  Moving into a new Home isn't complete yet (apparently!) so I expect to have more time available soon.  I haven't even started on the installer yet...

I still regard the traditional AMOS platform as being worthwhile.  It's major benefit and appeal (to me anyway) is the ability to program both at higher abstractions ("Just put the bl**dy sprite on the screen and move it will ya!") and right down to the bare metal ("So, if I Peek here I get the X offset and if I Doke it there I can change the colour.").  With the bugs all smoothed out and the compiler fixed and the docs up-to-date, it will be a reliable language.  With support for ECS and AGA (in the same style, as discussed in depth elsewhere) it becomes even more useful (I would have said loveable before I started chasing some of the more obscure bugs!  ).

So that's as far as I would like to see it go personally.  But good luck if you want to create a new OOP language for the Amiga with an AMOS-like feel to its abstractions.  Just make sure it is an OOP and not a compromise.

[SamuraiCrow]

@bruceuncle

If it uses OOP.library it will support multiple inheritance.  VBA was a joke and not that funny of one.  Also, I think OOP would only benefit the bank structure.

If you think going too low-level is a problem for OOP languages, it would be a simple matter to implement a full OOP wrapper around the banks.  In fact, the only big problem I see would be converting the bank numbers into an associative array of handles.

Fortunately, however, I don't see any desperate need for it now.  I'd be happy to be programming in PortablE instead.  Sidewinder and I had tried to implement an OOP variant of Amos called Mattathias but we got bogged down in implementation details and feature creep.

Perhaps this can all wait until AmosPro v4.x or something.  However, if we are going to support Aros 68k, OOP.library is going to be an important part of it since it is part of the Aros kernel.  I suspect that an extended subset of the Java Classpath will emerge in raw binary form for Aros and Arix.

[Hungry Horace]

Yes, it'll be a big step for AmosPro, OOP can bring Amos in a new kind of dimension, otherwise AmosPro still a good Fast Basic but nothing else

As far as I see it, that's exactly all that AMOS Pro *should* be ... the problem at the moment is the "fast" aspect of it (in terms of execution speed of compiled code)


On a side note;  I make a lot of my living out of VBA programming, so it amuses me that you are all bashing it!   I work in Building maintenance Project Management and people just see at as "stuff you do to make us more productive", what I would term as "process development" - whether its using Access databases, excel macros, outlook macros or preferably tools to link each to one-another.

I never use classes, and almost everything I've learnt stems back to what I have learnt from AMOS, and just expanded it into the VBA syntax. I try my best to use modules (but rarely share them between programs in their entirety) but do regularly re-use functions and Sub routines I've written, just as I do with functions and procedures in AMOS.


I would love to have the time to learn "proper" programming that involves classes / OOP etc, but even that would take valuable time away from project delivery and frankly even I find it confusing (possibly because of my 'BASIC' background, but I have several decent qualifications, so i'm no idiot!)  without having dedicated learning time for it, which I will probably never get (because it doesn't earn fees spending time learning "more correct methods" for process improvement)

But good luck if you want to create a new OOP language for the Amiga with an AMOS-like feel to its abstractions.  Just make sure it is an OOP and not a compromise.

Exactly this - if AMOS went down this route, I would end up sticking to AMOSPro 2.  If I wanted OOP or more advanced programming methods, I would use something else.

[bruceuncle]

Yes, it'll be a big step for AmosPro, OOP can bring Amos in a new kind of dimension, otherwise AmosPro still a good Fast Basic but nothing else

As far as I see it, that's exactly all that AMOS Pro *should* be ... the problem at the moment is the "fast" aspect of it (in terms of execution speed of compiled code)

But good luck if you want to create a new OOP language for the Amiga with an AMOS-like feel to its abstractions.  Just make sure it is an OOP and not a compromise.

Exactly this - if AMOS went down this route, I would end up sticking to AMOSPro 2.  If I wanted OOP or more advanced programming methods, I would use something else.

My point exactly.  I want to get AMOS Pro working as intended and, above all, reliable.  Then address the speed (as much as is possible under its current architecture) and future enhancements (ECS/AGA and the "best of the rest").  Otherwise it isn't really AMOS any more 

I may have seemed to be a bit harsh in my comments about an OO AMOS Pro language.  But at least I didn't ask "What's the point?"  I do understand where you guys are coming from and applaud the aspiration.  It just won't be AMOS, that's all.

On a side note;  I make a lot of my living out of VBA programming, so it amuses me that you are all bashing it!   I work in Building maintenance Project Management and people just see at as "stuff you do to make us more productive", what I would term as "process development" - whether its using Access databases, excel macros, outlook macros or preferably tools to link each to one-another.

I never use classes, and almost everything I've learnt stems back to what I have learnt from AMOS, and just expanded it into the VBA syntax. I try my best to use modules (but rarely share them between programs in their entirety) but do regularly re-use functions and Sub routines I've written, just as I do with functions and procedures in AMOS.


I would love to have the time to learn "proper" programming that involves classes / OOP etc, but even that would take valuable time away from project delivery and frankly even I find it confusing (possibly because of my 'BASIC' background, but I have several decent qualifications, so i'm no idiot!)  without having dedicated learning time for it, which I will probably never get (because it doesn't earn fees spending time learning "more correct methods" for process improvement)

He, he.  So did I  .  The vast majority in Access V1.0 (ugh!) V1.1 (still ugh!) Access 95 (crashed all the time!) Access 2000 (that's better) 2003 and straight to 2010 (pretty damned good!).

I did progress it to an object broker for singleton classes, a multiple instance forms manager and a message manager for inter-form communication to retain context across the workspace.  Also a class generator that just needed pointing to some Access tables to produce fail-safe, bullet proof classes for the data manipulation.  It was a lot of hard work and one really needed to concentrate to keep a sense of OOP about it.  But it made an investment bank (and me!) very happy and eventually paid off the mortgage when I went solo.  I still love it as it's so familiar and I've got all the infrastructure (= Access framework in Messysoft speak) to knock things up quick and easy.  All the AMOS Pro Docs, Help File and Sources data is stored and manipulated in Access databases.  Which is where I programmed the WYSIWYG editor so I can see the results formatted as they would appear on an AMOS Pro screen whilst still being able to edit them as for the Reference Manual.

I've also got a side project for the Resource V6.06 Help Files.  Piece of cake compared to AMOS    .  And, having "Resourced" Resource's libraries to get at the data, it's tempting to fix the bugs in it.  (It assumed line feeds after each link then someone forgot to program the hypertext engine to recognise that.  Putting the line feeds in and reassembling would fix it, but with 368 "articles" that can wait for another day.)

Did a lot in Excel too and hated it!  But it's great for producing custom charted reports and stuff.  Lousy possibilities for making secure applications out of it though.

If you want a basic OO-style Access framework to play with, let me know.  But don't expect it to be well documented.  I was flat out doing "productive" work when I built it and, like the plumber with the leaking tap, sort of never really got around to it  .

So I'm knocking it tongue-in-cheek so to speak (which really is impossible with one's tongue in one's cheek  )

[SamuraiCrow]

Ok, to wrap this up, I'll ask that AGA and perhaps CGX 3 support (included with AROS) should be the only things added in 3.x?  Perhaps hash-table support as native associative arrays would help but is optional.  Full OOP need not be added until 4.x or later (if ever).

[Lonewolf10]

On a side note;  I make a lot of my living out of VBA programming, so it amuses me that you are all bashing it!

I have been using VBA for the past year or so. It's certainly great for macro's and creating tools. I occasionally have to code some stuff for work (Windows XP), but I don't think I'd like to make a career out of it.

As for all the other discussions, some extra features and support in newer versions of AMOS would certainly be appreciated, but we need a stable reliable bit of software first.

[SamuraiCrow]

This is in the Amos 3.0 forum.  The 2.1 branch is the bug fixes release.

Even if we don't get OOP in 3.0, I would still like to see more data structure support.