The new PB Objects - a really needed feature

[Theo Gottwald]

Last week I created my first Object for a "real world program".
Was not for testing, was for immediate usage in a programm that had to be ready on that day.

While understanding the system better, i reminded myself that in earlier days before PB 9,
I had a wish to have something like the "VB Class-Modules".

Or lets say - a chance to split a big project in small sub-elements,
which may even be re-usable.

Bigger then Sub's or Functions. With "Themes" like "DATE, STRING, ... like that.

Like a "Date Class" with all sorts of Date-Calculation, a "Array Class" which provides dynamic string Arrays like a virtual Listbox etc.
and much more.

Starting a new Project then would begin just "Like shopping"!
I take those objects I may need.
And then immediately start organizing the structure.

At the end the result will definitely be a bit bigger then if I really "hand select" each function or procedure I'd maybe need.
But the time saving effect will be there, and may be significant. Also if those Modules are tested, the reliability will decrease debuggin times.

And to come back to the point. INHERITANCE, COM and INSTANCES ...
If we just leave all of this "next Level COM" stuff asside, CLASS MODULES is what we got.

We got a chance to organize Subroutines of a theme into an object (as CLASS METHODS).

We have to use PROPERTIES to get information and set Informations.
And we have a complete set of local Datatypes. Even dynamic string for these Modules.
They will be automatically initialized using the CREATE() - Method.
Thats great - its like a small program!

For that reason, I think the new compiler is a tool, even those should take a closer look,
who may not be interested in real "object oriented thinking".

But just in shorter Application developement times.

If I look back to the result, I found a lot of "CLASS METHODS" in there.
I found a long "CREATE()" and a very short DESTROY() - because PB destroys everything by itself.

The INTERFACE itself was not very big compared to the rest.
Just like an INTERFACE.

Now few days are gone, and if I look at the programm again,
its still really good readable, and i could make changes at any time.

I like the new possibilities.
PB is now - more then ever - ready for bigger Projects.

This is my conclusion after my first Object, on the new Possibilites.
Any comments?

[Edwin Knoppert]

I don't want to sound to negative, i am very happy we have classes now but..
I strongly believe that Classes in PB can only improve things when PB has more advanced way to embed functionality.
The next best thing PB could bring is static linking.
If you create a lib, only the part actually used is embedded into the exe.
Right now you can 'only' prepare run-time's like VB does.
Iow you will gain easier programming but the application will be bigger as needed.

For example your 'date' class will most likely an extensive module.
Tons of good functions but what if i just want to use 1 or 2 functions?
To substantially improve programming experiance, optimized linking is imo required.

Note that static linking is often mentioned for third part developers.
This is true but only a secundary thing for most of the common users.
Of course, i would like to use a static lib for my PwrDev, right away.
I do that with PwrC, a static lib keeps the app really small.

[James C. Fuller]

Edwin,
  I learned how to live without static linking a long time ago and it has served me well. I use #IF %DEF(%Use_xxxx) #ENDIF around all my library functions. I also try to keep my classes small and use the same method. It's second nature now.

I am completely addicted to Classes and will never look back!!

James

[Edwin Knoppert]

That is called a work-around.

[James C. Fuller]

That is called a work-around.

Not at all.
I went down the static library route with FreeBasic and it was a real pia.
I thought hey I'll put all my library routines in a static library and then they will only
be linked it if I use them. So I compiled them into an .o file and created a .lib. ?? How
come my exe is the same size. Oops. I had to compile each function (or group of related) into separate .o files and then put them individually into the .lib file. If I needed to make any changes I had to go through the whole process all over. I ended up doing the same as I do now with #ifdef's. Much more flexible. For large libraries ? That's what dll's and .so's are for.

James

[Theo Gottwald]

First I'd generally say that i like the idea from Purebasic to just compile the really used Sub's into the final EXE.
It is built into Purebasic for long time in this way. Personally i think that they are doing a lot of good things there and I never regret to buy this Purebasic licence.
Even though I could not use it for something "real" until now, I can imagine, that it is usable for a lot of things.
They are also improving in their product with each new version. Seems they have added a underlying C Compiler.

I am using this chance to take a look after long time ...(see below)*

Hmmm ...  I am not sure if the translation of "Quite some bugs" is accurate.
The german page says "Viele".
And the translation should have been "Many", which means "Many bugs" have been corrected.
"Quite some bugs" would be translated with "Einige Fehler". Anyway, they did not say how many are left then.

In nature there are places, where bugs like to live. Thats for environmental reasons.
You can go there and kill 100 bugs, but this does not mean that now there are no more bugs left.
It means there are for sure enough left in some dark corners.
Therefore if you don't like these insects so much, the only chance is to look for places where the environment is not good for them.
Maybe to cold or no food ... ?
So I may want to wait some time more before I take a look - maybe until Version 5 or 6 ...?

Second I am also using the workaround, James is using. Actually its easier, just add #INCLUDE ONCE "..." anywhere.
While i believe that this command could have been more carefully designed. 90% of its usagen it is used as "#INCLUDE ONCE".
Therefore it should have been designed as "#INCLUDE ALWAYS" - if needed - and the "ONCE" as the default beavior.

But back to the Object-Modules. Yes, the resulting code may be bigger then needed.
It may on the other side be even smaller if i hardcode it directly in ASM :-).

Of course, if I only need 1 or 2 Subs, I may just search them and include them directly.
Or I may decide the 4  or 20 kb more in size are in no way interesting for this project and just take all needed "Modules together".

Or I may even make a Template with the 5 most often needed Modules and start right middle in the race.
At the end all my app's would have a similar size, whatever they do.

The point about it is that the resulting size of the executable does not interest nobody on the customer side.
Does it have 64 kb or 1 MB?  The customer actually beeing used to DOTNET doesn't really care.

He wants something that does X, he did not say "I want something that does X and is below 200 kb".
But he might say "I want it yesterday".

Therefore the Modules are a big step ahead. Looking at the access-numbers in my sub-forum, i see that size matters.
At least this post hast most viewers. But we don't know what they may have searched in google for so they came here ... :-)

---------------------------
* http://www.purebasic.com/german/news54.php3

- Optimiert: Geschwindigkeit des Compilers beim verarbeiten des Codes (bis zu 8x schneller)
- Optimiert: Alle Befehle profitieren vom Verwenden eines besseren C Compilers (nur unter Windows)
- Repariert: Viele Bugs im Compiler und den Bibliotheken

Translation on the english page:
This is - Optimized: Compiler source processing speed (up to 8x faster)
- Optimized: The whole commandset by using a better C compiler (Windows only)
- Fixed: Quite some bugs related to the commands and compiler

[Edwin Knoppert]

>How come my exe is the same size.

So you where using a poor compiler?
I *said* optimized.
A good c compiler does this fine.

You simply include on demand but manually.
A good compiler does this for you, why want to do it manually?
Only because the compiler doesn't do it right now.

Regarding the PB compiler, there is enough to wish for.

[Edwin Knoppert]

>The point about it is that the resulting size of the executable does not interest nobody on the customer side.
Does it have 64 kb or 1 MB?  The customer actually beeing used to DOTNET doesn't really care.

PB creates stand alone exe's, would not like those to be having a default size of 1MB, would you?
.NET is using a runtime, the exe's are small.
A different approach you can not compare.

[Theo Gottwald]

So you where using a poor compiler?
I *said* optimized.

:-) I am not using a poor compiler, to my best knowledge.
Especially, as I prefer a compiler who may give me a few kb more.
If the resulting programm does exactly what I have expected, thats the price I am willing to pay.

If I'd really see a sense in my case, in loosing a bit weight (in the compiled exe only, I am not too fat myself .-),
then I'd just try my good old PureBasic licence or use MASM.

But actually its safe on a DVD, and I can't say when I'll ever take it out.

I like the new Objects.

And when using Objects and CLASS METHODS (as i suggested), I doubt any compiler will strip unused CLASS METHODS out.

Besides that, I agree that there are many open wishes to PB also.
I have already sent some in and I know others have too. Thats true for any compiler on the market that there are open wishes.

As said I would also support a feature which would only compile "used" functions into the final exe.
Actually I am not sure if this would need another pass at compiletime, but I would not care.