Classes in PureBasic
Re: Classes in PureBasic
Danilo is right. Even if Fred decides to add some OOP support,
it is highly unlikely that the implementation gets anywhere even remotely
close to that offered by other, native OOP languages.
So, you guys need to either learn how to write procedural code effectively,
or switch to another language if you can't be bothered (like I did, because pure procedural code
has no benefits whatsoever for anything but small projects and just makes coding more annoying).
For low-level purposes or explicit multi-platform I'd recommend D or C++,
for anything Windows related C#.
it is highly unlikely that the implementation gets anywhere even remotely
close to that offered by other, native OOP languages.
So, you guys need to either learn how to write procedural code effectively,
or switch to another language if you can't be bothered (like I did, because pure procedural code
has no benefits whatsoever for anything but small projects and just makes coding more annoying).
For low-level purposes or explicit multi-platform I'd recommend D or C++,
for anything Windows related C#.
Blog: Why Does It Suck? (http://whydoesitsuck.com/)
"You can disagree with me as much as you want, but during this talk, by definition, anybody who disagrees is stupid and ugly."
- Linus Torvalds
Re: Classes in PureBasic
To invalidate your ridiculous assertions, I will testify that as an expert programmer of over 39 years on real computers, I have no trouble with effectively desiging and implementing software using PureBasic.User_Russian wrote:In this case, on the main page of the site you need this text.Replace thisPureBasic has been created for the beginner and expert alike.And this textPureBasic has been created for the beginner only.Replace this.Experienced coders will have no problemExperienced programmers would have trouble in program design.
I think that is a great on topic question.Danilo wrote:@User_Russian:
Are you unable to learn any of the plenty OOP languages out there? Why can't you just use D, C#, or Ruby? It's easy.
Apparently the answer is that they can't do the job for him either.
Shield is correct about everything in the quote above except for the ridiculous statement about pure procedural code having no benefits outside of small projects, and being annoying.Shield wrote:Danilo is right. Even if Fred decides to add some OOP support,
it is highly unlikely that the implementation gets anywhere even remotely
close to that offered by other, native OOP languages.
So, you guys need to either learn how to write procedural code effectively,
or switch to another language if you can't be bothered (like I did, because pure procedural code
has no benefits whatsoever for anything but small projects and just makes coding more annoying).
I can only imagine how hard it must be to maintain the illusion that OO programming is more flexible or efficient, when classes at their core are procedural entities.
I know that's it is hard to give up on the OOP concepts that you've worked so hard to wrap your brain around,User_Russian wrote:All who oppose classes probably nothing not know about them! Nobody is forcing you to use OOP, but its implementation should be in PB!
so those who are working in a corporate environment unwilling to learn how to effectively program a computer using procedural languages,
should move on to middle management, into a different career, or be resigned to being a little cog in a big machine.
because the object oriented paradigm is a tool of the corporate masters to control the computer environment, so ultimately they don't have to depend on humans.
It's all about freedom baby!
Keep it BASIC.
Re: Classes in PureBasic
Fred is saying for 10+ years now that he wants PB to stay procedural.User_Russian wrote:I need a system language and PB in most of the suitable. But there are some drawbacks, including a lack of OOP.
If PB does not change to what you would like it to be, you need to change yourself
and learn to use another OOP language.
There are even BASIC OOP languages available. Maybe you would like it:
Code: Select all
Type BaseType
Field a:Int, b:Byte, c ' default type is Int
Field s:String
Method New()
Print "Constructor invoked!"
a=10
End Method
Method Test()
Print "BaseType.Test"
End Method
End Type
Type DerivedType Extends BaseType
Method Test()
Super.Test 'calls BaseType's Test() method first!
Print "DerivedType.Test"
Try
Repeat
a:+1
Print a
If a>20 Then Throw "chunks"
Forever
Catch a$
Print "caught exception "+a$
EndTry
End Method
End Type
Local x:BaseType = New DerivedType
x.Test
Re: Classes in PureBasic
Please, I do not think it'd be useful seeing in others languages.
If I was not an asshole, I discovered this subject more earlier than today...
I think a new directive is necessary and just this:
"FreeSection"
All simply... It is the best way to the future. (Maybe is it available today I do not know...)
Else...
Here (same as below but easier to read), there is an approach of OOP syntax.
Below is a manual header (first code, the second one is one of the available tests). An automatic header already exists but it just grow the availability of items and arguments. Really, the limit is in the internal "functions" of the macros. If we had a free section handled as a datasection but without the syntax ' read.s "" ', etc..., a major part of the problem would be solved.
A small example:
A longer example:
If I was not an asshole, I discovered this subject more earlier than today...
I think a new directive is necessary and just this:
"FreeSection"
Code: Select all
CompilerSetEndFreeSection(EndFreeSection)
FreeSection MyOwnSection
/* yep ! */
Here is not the problem of the compiler neither the one of the editor...
/!\ Here is what I want...
&
@@ double bigoudi
EndFreeSection
ExamineSection(?MyOwnSection)
While NextFreeString()
A$ = GetFreeString()
Debug A$
Wend
Else...
Here (same as below but easier to read), there is an approach of OOP syntax.
Below is a manual header (first code, the second one is one of the available tests). An automatic header already exists but it just grow the availability of items and arguments. Really, the limit is in the internal "functions" of the macros. If we had a free section handled as a datasection but without the syntax ' read.s "" ', etc..., a major part of the problem would be solved.
Code: Select all
;{ Macro }
Macro Quo
"
EndMacro
Macro C_(Object, Method)
CallFunctionFast(Object#\Method, Object)
EndMacro
Macro Inherit(Inherited, Inheriting)
Protected *Inherited.Inherited = *Inheriting\Inherited
EndMacro
Macro RootInherit(Inherited, Inheriting)
Shared Inherited
*Inheriting\Inherited = Inherited
EndMacro
Macro oo
(A,B=,C=,D=,E=,F=,G=,H=,I=,J=,K=,L=,M=,N=,O=,P=,Q=,R=,S=,T=,U=,V=,W=,X=,Y=,Z=,A2=,B2=,C2=,D2=,E2=,F2=)
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
A2
B2
C2
D2
E2
F2
EndMacro
Macro Builder(Obj, M1, C1)
Procedure Obj#M1(*Obj.Obj)
C1
EndProcedure
Obj\M1 = @Obj#M1()
EndMacro
Macro Class(Obj,ArgSet,M1,C1,M2=EndC,C2=,M3=EndC,C3=,M4=EndC,C4=,M5=EndC,C5=,M6=EndC,C6=,M7=EndC,C7=)
Structure Obj
ArgSet
*M1
CompilerIf Quo#M2#Quo <> Quo#EndC#Quo
*M2
CompilerIf Quo#M3#Quo <> Quo#EndC#Quo
*M3
CompilerIf Quo#M4#Quo <> Quo#EndC#Quo
*M4
CompilerIf Quo#M5#Quo <> Quo#EndC#Quo
*M5
CompilerIf Quo#M6#Quo <> Quo#EndC#Quo
*M6
CompilerIf Quo#M7#Quo <> Quo#EndC#Quo
*M7
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
EndStructure
Define Obj.Obj
Builder(Obj, M1, C1)
CompilerIf Quo#M2#Quo <> Quo#EndC#Quo
Builder(Obj, M2, C2)
CompilerIf Quo#M3#Quo <> Quo#EndC#Quo
Builder(Obj, M3, C3)
CompilerIf Quo#M4#Quo <> Quo#EndC#Quo
Builder(Obj, M4, C4)
CompilerIf Quo#M5#Quo <> Quo#EndC#Quo
Builder(Obj, M5, C5)
CompilerIf Quo#M6#Quo <> Quo#EndC#Quo
Builder(Obj, M6, C6)
CompilerIf Quo#M7#Quo <> Quo#EndC#Quo
Builder(Obj, M7, C7)
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
EndMacro
Macro MakeObject(Obj, Index) ; In an array
*Obj(Index) = AllocateMemory(SizeOf(Obj) )
CopyMemory(*Obj, *Obj(Index), SizeOf(Obj) )
EndMacro
;}
A small example:
Code: Select all
; ici un 'define' est produit pour pouvoir exécuter le test plus bas...
Class(Calcul,
Entier.I,
MetAZero,
*Calcul\Entier = 0,
Incremente,
*Calcul\Entier + 1,
Decremente,
*Calcul\Entier - 1,
Double,
*Calcul\Entier * 2,
Affiche,
MessageRequester("Valeur de l'entier", Str(*Calcul\Entier) ),
)
CalculMetAZero(Calcul) ; v = 0
CalculIncremente(Calcul) ; v = v + 1 donc v = 1
CalculDouble(Calcul) ; v = v * 2 donc v = 2
CalculAffiche(Calcul)
CallFunctionFast(Calcul\Affiche, Calcul) ; une autre méthode d'appel...
C_(Calcul, Affiche) ; encore une autre...
; Allez une dernière de tête (illuminée, affichera 8)
; (si pas d'erreur)
A$="122445" ; un "programme"
for i=1 to len(a$)
callfunctionfast(Calcul + 4 * (val(mid(A$,i,1))), Calcul)
next
Code: Select all
;*****************************************************************************************
; ***************************************** CODE ****************************************
;*****************************************************************************************
Class(Device,
oo( Sprite.I,
Keyboard.I,
Mouse.I,
ErrorMessage.S,
),
Init,
oo( *Device\Sprite = InitSprite(),
If *Device\Sprite,
*Device\Keyboard = InitKeyboard(),
*Device\Mouse = InitMouse(),
EndIf,
),
SendError,
oo( MessageRequester("Device error", *Device\ErrorMessage),
End,
),
Check,
oo( If *Device\Sprite = #False,
*Device\ErrorMessage = "Device subsystem is not installed !",
C_(*Device, SendError),
EndIf,
If *Device\Keyboard = #False,
*Device\ErrorMessage = "Keyboard is not installed !",
C_(*Device, SendError),
EndIf,
If *Device\Mouse = #False,
*Device\ErrorMessage = "Mouse is not installed !",
C_(*Device, SendError),
EndIf,
),
)
Class(Desktop,
oo( Current.I,
Quantity.I,
Width.I,
Height.I,
Depth.I,
Frequency.I,
),
Examine,
oo( *Desktop\Quantity = ExamineDesktops(),
*Desktop\Width = DesktopWidth(*Desktop\Current),
*Desktop\Height = DesktopHeight(*Desktop\Current),
*Desktop\Depth = DesktopDepth(*Desktop\Current),
*Desktop\Frequency = DesktopFrequency(*Desktop\Current),
),
)
Class(Screen,
oo( Handle.I,
Width.I,
Height.I,
Depth.I,
Title.S,
Modified.I,
Color.I,
*Desktop,
),
Open,
*Screen\Handle = OpenScreen(*Screen\Width, *Screen\Height, *Screen\Depth, *Screen
\Title),
Close,
oo( If *Screen\Handle,
CloseScreen(),
EndIf,
),
Clear,
oo( *Screen\Modified = #True,
ClearScreen(*Screen\Color),
),
Flip,
oo( If *Screen\Modified = #True,
FlipBuffers(),
EndIf,
),
ImportResolutionFromDesktop,
oo( Inherit(Desktop, Screen),
*Screen\Width = *Desktop\Width,
*Screen\Height = *Desktop\Height,
*Screen\Depth = *Desktop\Depth,
),
)
Class(Processor,
oo( Duration.I,
Clock.I,
),
SetDelay,
Delay(*Processor\Duration),
GetClock,
*Processor\Clock = ElapsedMilliseconds(),
)
#RegionType_Rectangle = 1
#RegionDisplayMode_Direct = 1
Class(Region,
oo( *Parent,
X1.I,
Y1.I,
X2.I,
Y2.I,
Width.I,
Height.I,
Type.I, ; Cf constants
FrontColor.I,
DisplayMode.I, ; Cf constants
*Desktop,
),
CreateDirectRectangle,
oo( *Region\Type = #RegionType_Rectangle,
*Region\DisplayMode = #RegionDisplayMode_Direct,
),
SizeFromDesktop,
oo( Inherit(Desktop, Region),
*Region\X1 = 0,
*Region\Y1 = 0,
*Region\X2 = *Desktop\Width - 1,
*Region\Y2 = *Desktop\Height - 1,
*Region\Width = *Desktop\Width,
*Region\Height = *Desktop\Height,
),
SizeFromParent,
oo( Protected *Parent.REGION,
*Parent = *Region\Parent,
*Region\X1 = *Parent\X1,
*Region\Y1 = *Parent\Y1,
*Region\X2 = *Parent\X2,
*Region\Y2 = *Parent\Y2,
*Region\Width = *Parent\Width,
*Region\Height = *Parent\Height,
),
RandomizeColor,
*Region\FrontColor = RGB(Random(255), Random(255), Random(255) ),
Output,
oo( Select *Region\DisplayMode,
Case #RegionDisplayMode_Direct,
StartDrawing(ScreenOutput() ),
EndSelect,
Select *Region\Type,
Case #RegionType_Rectangle,
Box(*Region\X1, *Region\Y1, *Region\Width, *Region\Height, *Region
\FrontColor),
EndSelect,
StopDrawing(),
),
)
Class(Software,
oo( *Device,
*Desktop,
*Screen,
*Processor,
*Region,
QuitFlag.I,
StandByDelay.I,
StandByClock.I,
),
Init,
oo( RootInherit(Device, Software),
RootInherit(Desktop, Software),
RootInherit(Screen, Software),
RootInherit(Processor, Software),
RootInherit(Region, Software),
),
Start,
oo( C_(*Software, Init),
Inherit(Device, Software),
Inherit(Desktop, Software),
Inherit(Screen, Software),
C_(*Device, Init),
C_(*Device, Check),
*Desktop\Current = 0,
C_(*Desktop, Examine),
*Screen\Desktop = *Desktop,
C_(*Screen, ImportResolutionFromDesktop),
*Screen\Title = "Untitled",
C_(*Screen, Open),
*Screen\Color = RGB(0, 0, 0),
C_(*Screen, Clear),
C_(*Screen, Flip),
),
Finish,
oo( Inherit(Screen, Software),
C_(*Screen, Close),
),
Wait,
oo( Inherit(Processor, Software),
*Processor\Duration = 2000,
C_(*Processor, SetDelay),
),
StandBy,
oo( Inherit(Processor, Software),
If *Software\StandByClock = 0,
*Software\StandByClock = *Processor\Clock + *Software\StandByDelay,
Else,
If *Processor\Clock > *Software\StandByClock,
*Software\QuitFlag = #True,
EndIf,
EndIf,
),
Interface,
oo( C_(*Software, Start),
Inherit(Processor, Software),
Inherit(Region, Software),
Inherit(Desktop, Software),
Inherit(Screen, Software),
*Processor\Duration = 1, ; (milliseconds)
*Software\StandByDelay = 3000, ; (milliseconds)
Dim *Region.REGION(255),
C_(*Region, CreateDirectRectangle),
*Region\Desktop = *Desktop,
C_(*Region, SizeFromDesktop),
C_(*Region, RandomizeColor),
MakeObject(Region, 0),
C_(*Region, CreateDirectRectangle),
*Region\Parent = *Region(0),
C_(*Region, SizeFromParent),
*Region\Height = 32,
C_(*Region, RandomizeColor),
MakeObject(Region, 1),
Repeat,
C_(*Processor, GetClock),
C_(*Processor, SetDelay),
C_(*Software, StandBy),
*Region = *Region(0),
C_(*Region, Output),
*Region = *Region(1),
C_(*Region, Output),
C_(*Screen, Flip),
Until *Software\QuitFlag,
C_(*Software, Finish),
),
)
;
C_(Software, Interface)
-
- Addict
- Posts: 1518
- Joined: Wed Nov 12, 2008 5:01 pm
- Location: Russia
Re: Classes in PureBasic
For my tasks enough of this, with the possibility of inheritance and the presence of the constructor and destructor. http://www.purebasic.fr/english/viewtop ... 95#p454795Danilo wrote:There are even BASIC OOP languages available. Maybe you would like it
Re: Classes in PureBasic
This is obvious. Fred would not even have to do anything super creative to implement it so it was totally backwards compatible, yet those adamantly against it have such a small grasp that they say little more than "Wrong."Alexi wrote:The most ones against oop, just don't understand it.
Re: Classes in PureBasic
Those few users are not the problem. The only problem is, the boss does not want it.Alexi wrote:The most ones against oop, just don't understand it.
Fantaisie Software decides what gets implemented, and what not. You know that.
Fantaisie Software does custom work. You can ask them by e-mail what it would cost to implementAlexi wrote:I would clearly pay another 100-200$ for this.
any certain feature. I doubt they can implement OOP within 2 hours, so after getting Fred's opinion changed,
it would probably be more expensive.
A kickstarter or something similar would help to share the price. Set a goal (5,000 or 10,000 Euro or whatever it would cost),
and if the goal is reached, it gets implemented properly. Only Fantaisie Software could do that for their product.
Before thinking about those possibility, Fred has to change his opinion. As long as he resists, it will not get implemented internally,
so your only option is to use a pre-processor or compiler that translates OOP syntax to procedural PB.
Re: Classes in PureBasic
Don't do it for anything less than 200,000$ because once you let them in, rest assured, they will try to take over.Alexi wrote:I would clearly pay another 100-200$ for this.
It's in their nature.
Give them an inch.... and it's class warfare.

Keep it BASIC.
Re: Classes in PureBasic
Very ancient, old-fashioned opinion, heartbone. Programming is a service you do for customers, and those paying
customers say what they want and the company's service is to implement it for them. Of course the
implementation details should be the final decision of the expert developers in the company, but it is
the customers that give the general direction of any product.
The customer is king. The customer is always right. The customer rules everything. The customer comes first. The customer puts food on your table.
That's also the modern principle of Kickstarter. There are goals, and interested customers are willing to pay for it.
If the goal is reached ($$$), it means enough customers are interested, and it is payed/funded already, by customers.
The company then has to deliver what the customers payed for.
If a goal is not reached, it gets not implemented, and nobody pays something. It means there is not enough interest by the customers.
Did you ever take note that more and more old-fashioned business are struggling and dying, while modern and flexible business make millions upon millions?
Vote now for 'PureBasic Professional' Kickstarter!

customers say what they want and the company's service is to implement it for them. Of course the
implementation details should be the final decision of the expert developers in the company, but it is
the customers that give the general direction of any product.
The customer is king. The customer is always right. The customer rules everything. The customer comes first. The customer puts food on your table.
That's also the modern principle of Kickstarter. There are goals, and interested customers are willing to pay for it.
If the goal is reached ($$$), it means enough customers are interested, and it is payed/funded already, by customers.
The company then has to deliver what the customers payed for.
If a goal is not reached, it gets not implemented, and nobody pays something. It means there is not enough interest by the customers.
Did you ever take note that more and more old-fashioned business are struggling and dying, while modern and flexible business make millions upon millions?
Vote now for 'PureBasic Professional' Kickstarter!


Re: Classes in PureBasic
I like this really cool idea!Danilo wrote:That's also the modern principle of Kickstarter. There are goals, and interested customers are willing to pay for it.
If the goal is reached ($$$), it means enough customers are interested, and it is payed/funded already, by customers.
The company then has to deliver what the customers payed for. If a goal is not reached, it gets not implemented, and nobody pays something. It means there is not enough interest by the customers.
Fred earns even more money from existing customers and PureBasic gets more professional for more new customers.
PB 5.70 LTS (x64) - Debian Testing, Gnome 3.30.2
Re: Classes in PureBasic
Amazing...Just amazing.
117 (118 now) posts - almost all written by the same approx. 15 pro oop advocates.
A firm 'NO!' from Fred is apparently negotiable in the eyes of those 15 users.
I got nothing against oop and if it was part of PureBasic - I would use it,
but I certainly do accept that, when Fred says 'no' it is a 'no'.
I knew, when I bought PureBasic, that OOP wouldn't be part of the language and
so did all of you. It is still a powerfull language with all the bells and whistles.
My advice: use PureBasic or develop in something else.
@User_Russian:
The time you've used bitching about the lack of oop, is time you could have used to realize you project in another language.
@Danilo
Personally I think, that the majority buying PureBasic haven't got 'big pockets - not even small ones'.
They searched the net for cheap language with a steady support service and stumbled into PureBasic.
From what I've seen so far, only a VERY small number of users actually produces any kind of revenue using PureBasic.
The silent majority are most likely hobbyists (like me. Ordinary wageslaves - doing freeware only), newbies and wannabees/(dreamers).
Yes..businesses are dying...fast..period. It's the way we've designed our social and economic structure.
Modern businesses are pure sharks and greed is rewarded handsomely by our system.
Only a minor fraction of businesses makes it nowadays, while the majority of new companies often
succumb to external corporate pressure and hostile takeovers.
Most new businesses won't last two years unless they have a new 'patented' product, a strong economic foundation and massive online exposure.
Business is war.
The main reason, that PureBasic has survived this long is due to Fred's love for his baby.
PureBasic won't ever become a multi-million dollar business but it will live on as long as Fred and the team
enjoys developing it and there are users to back it up. (Which certainly doesn't require oop implementation).
So....Please...stop beating a dead horse and lets all muster some patience and see where Fred and the team takes PureBasic.
The path has been truly interesting so far.
https://www.youtube.com/watch?v=MjoMQJf5vKI
117 (118 now) posts - almost all written by the same approx. 15 pro oop advocates.
A firm 'NO!' from Fred is apparently negotiable in the eyes of those 15 users.
I got nothing against oop and if it was part of PureBasic - I would use it,
but I certainly do accept that, when Fred says 'no' it is a 'no'.
I knew, when I bought PureBasic, that OOP wouldn't be part of the language and
so did all of you. It is still a powerfull language with all the bells and whistles.
My advice: use PureBasic or develop in something else.
@User_Russian:
The time you've used bitching about the lack of oop, is time you could have used to realize you project in another language.
@Danilo
Personally I think, that the majority buying PureBasic haven't got 'big pockets - not even small ones'.
They searched the net for cheap language with a steady support service and stumbled into PureBasic.
From what I've seen so far, only a VERY small number of users actually produces any kind of revenue using PureBasic.
The silent majority are most likely hobbyists (like me. Ordinary wageslaves - doing freeware only), newbies and wannabees/(dreamers).
Yes..businesses are dying...fast..period. It's the way we've designed our social and economic structure.
Modern businesses are pure sharks and greed is rewarded handsomely by our system.
Only a minor fraction of businesses makes it nowadays, while the majority of new companies often
succumb to external corporate pressure and hostile takeovers.
Most new businesses won't last two years unless they have a new 'patented' product, a strong economic foundation and massive online exposure.
Business is war.
The main reason, that PureBasic has survived this long is due to Fred's love for his baby.
PureBasic won't ever become a multi-million dollar business but it will live on as long as Fred and the team
enjoys developing it and there are users to back it up. (Which certainly doesn't require oop implementation).
So....Please...stop beating a dead horse and lets all muster some patience and see where Fred and the team takes PureBasic.
The path has been truly interesting so far.
https://www.youtube.com/watch?v=MjoMQJf5vKI
Current configurations:
Ubuntu 20.04/64 bit - Window 10 64 bit
Intel 6800K, GeForce Gtx 1060, 32 gb ram.
Amd Ryzen 9 5950X, GeForce 3070, 128 gb ram.
Ubuntu 20.04/64 bit - Window 10 64 bit
Intel 6800K, GeForce Gtx 1060, 32 gb ram.
Amd Ryzen 9 5950X, GeForce 3070, 128 gb ram.
-
- Enthusiast
- Posts: 118
- Joined: Thu May 17, 2007 8:35 pm
- Location: USA
Re: Classes in PureBasic
Danilo sorry to hijack this thread albeit temporarily..
can you check your PM or go to this thread and chime in on this subject if you have time? thanks!
http://www.purebasic.fr/english/viewtop ... =5&t=60950
ok now rant on about OOP!
can you check your PM or go to this thread and chime in on this subject if you have time? thanks!
http://www.purebasic.fr/english/viewtop ... =5&t=60950
ok now rant on about OOP!
Re: Classes in PureBasic
In truth half of these posts are about the possible implementation of modules.DK_PETER wrote: 117 (118 now) posts - almost all written by the same approx. 15 pro oop advocates.
Translated it just means "I'm not willing to do it right now and I don't see something able to change my mind.".DK_PETER wrote:A firm 'NO!' from Fred is apparently negotiable in the eyes of those 15 users.
Believing absolutely, positively, you will never do something "period." is absurd, you can't know what life could bring to you to change your mind.
On the other hand repeating the same old things forever I don't think is what it will make it happen, since the reaction to all this historically has been fiercely negative. So insisting is equally absurd and probably annoying.
Offering enough money it's the first obvious try it comes to mind.
Almost everyone likes money since you can readily convert it into many other things, where the posts asking for OOP can be readily converted just into a headache.
No one tried it yet AFAIK so I will not dismiss it on principle.
I too think the kickstarter idea is the best, this is if the idea could make Fred salivate enough to try it.
The good thing in case of failure in reaching the requested sum, is people asking for OOP would have to shut up forever about that, and new people asking for OOP could be redirected to the failed kickstarter page.
But I also see some problems with it.
One problem is I don't see this successful unless the target is modest.
PB has 8000+ users (2012), but I don't know how many of them are really active, using it, and willing to pay something extra for a feature they didn't consider mandatory when they bought PB.
Another problem is all this is against PB philosophy of the perpetual license, buy it once forever.
New features are added at no extra cost, so why this should be different ?
Fred could have chosen a different license model from the start, or change it along the way but he didn't, so maybe a little more money wouldn't make him change his mind.
Another problem is I'm quite sure there would be a lot of fragmentation in what people expect from it.
Fred would propose the OOP implementation he's going to add to PB and some people would start to say it's not enough.
"I will not pay for simple objects only, I want inheritance too".
"What's the use of objects if I cannot link C++ library to PB ? I want to be able to do that too".
You get the idea.
So the potential user base, immediately cut in half or less by the "active" factor, it is further reduced by the "I'm not interested in OOP enough/at all" factor, and a little more by the "This is not what I NEED/WANT/HOPED".
You can reduce it a little more with the "petty reasoning" factor.
"Why the ones paying are so few ? Why *I* must pay for this ? Why the other users have to get it for free ? AH! They say don't want it but I bet they will use it right away ! Despicable creatures ! I'll tag them in the forum !"
So, I'm not very optimist about that.
An alternative course of action could be to buy a dog for Fred, wait one year to make them bond, kidnap the puppy and blackmail him.
We just have to hope he's soft enough.
"Have you tried turning it off and on again ?"
A little PureBasic review
A little PureBasic review
Re: Classes in PureBasic
Slightly offtopic:
But since then PureBasic has matured a lot. Maybe the results are simply outdated so that it's time for another poll. If someone is interested in the raw material to create a new one I'd be happy to help (unfortunately I don't have time for that otherwise I'd love to do it myself).
I'd say most of the users simply don't brag about it (why should they?) because the results from the PureBasic Poll I initiated back in 2012 suggest something different. In fact of the participants about 40% had a professional intention (commercial and/or company internal) when using PureBasic, besides the appealing hobby/private programming.DK_PETER wrote:From what I've seen so far, only a VERY small number of users actually produces any kind of revenue using PureBasic.
The silent majority are most likely hobbyists (like me. Ordinary wageslaves - doing freeware only), newbies and wannabees/(dreamers).
But since then PureBasic has matured a lot. Maybe the results are simply outdated so that it's time for another poll. If someone is interested in the raw material to create a new one I'd be happy to help (unfortunately I don't have time for that otherwise I'd love to do it myself).
If any of you native English speakers have any suggestions for the above text, please let me know (via PM). Thanks!