Page 2 of 2
Re: Borrowing from Object Oriented systems
Posted: Sun Nov 24, 2013 6:21 pm
by BorisTheOld
AndrewM wrote:@BorisTheOld. What exactly does the example code in your recent post do?
This sample program demonstrates the use of macros, OOP, custom controls, and automatic resizing....
If you actually look at the code, and perhaps even execute it, you might find some answers to your questions about writing OOP-style programs with PB.
NOTE: This code will not work correctly with Windows when using PB 5.21 LTS. In certain situations, the Canvas "focus" events are not being created by PB.
Re: Borrowing from Object Oriented systems
Posted: Mon Nov 25, 2013 9:00 pm
by USCode
@BorisTheOld
What software products do you develop? Got a website?
Re: Borrowing from Object Oriented systems
Posted: Mon Nov 25, 2013 11:50 pm
by BorisTheOld
USCode wrote:What software products do you develop? Got a website?
Custom programming. No website.
Re: Borrowing from Object Oriented systems
Posted: Tue Nov 26, 2013 12:57 am
by USCode
BorisTheOld wrote:USCode wrote:What software products do you develop? Got a website?
Custom programming. No website.
Ah, gotcha, thanks. I only asked because you mentioned here "applications" and "production code" and I assumed it was a product you were marketing:
http://www.purebasic.fr/english/viewtop ... 00#p418103
Do you find your customers are ever hesitant with you using PureBasic for projects?
What made you choose PureBasic to convert your code over to vs. others such as XOJO (REALBasic), etc.?
Re: Borrowing from Object Oriented systems
Posted: Tue Nov 26, 2013 4:41 am
by BorisTheOld
USCode wrote:I only asked because you mentioned here "applications" and "production code" and I assumed it was a product you were marketing
I was just refering to our in-house code generators, and the like.
USCode wrote:Do you find your customers are ever hesitant with you using PureBasic for projects?
What made you choose PureBasic to convert your code over to vs. others such as XOJO (REALBasic), etc.?
I don't give them a choice. Our customers, who tend not to be programmers, are more concerned about whether stuff works than what it's made of. We've done work in COBOL, PL/I, Assembler, VB, PowerBasic, and now PB.
Our main language for the past few years has been PowerBasic, but I wanted to move into Linux. However, PowerBasic needs to run under Wine with Linux, and the results are not very inspiring. About six years ago I ran some trials with RealBasic, but it was too big and too buggy. I like using languages that have many features, but which can be pushed beyond their normal limits. So although PB is missing some of the standard BASIC features, it has the ability to work with many different libraries, on three platforms. Plus it can access dynamic libraries created by other languages. PB is flexible enough that we can write our own versions of BASIC features, such as the Format statement and the Currency data type. The example I linked to above, shows the kind of stuff we're doing.
PB must have something going for it if, after 50 years of programming, I choose to work with it rather than anything else.
Re: Borrowing from Object Oriented systems
Posted: Tue Nov 26, 2013 7:18 am
by USCode
BorisTheOld wrote:... I don't give them a choice. Our customers, who tend not to be programmers, are more concerned about whether stuff works than what it's made of. We've done work in COBOL, PL/I, Assembler, VB, PowerBasic, and now PB.
Our main language for the past few years has been PowerBasic, but I wanted to move into Linux. However, PowerBasic needs to run under Wine with Linux, and the results are not very inspiring. About six years ago I ran some trials with RealBasic, but it was too big and too buggy. I like using languages that have many features, but which can be pushed beyond their normal limits. So although PB is missing some of the standard BASIC features, it has the ability to work with many different libraries, on three platforms. Plus it can access dynamic libraries created by other languages. PB is flexible enough that we can write our own versions of BASIC features, such as the Format statement and the Currency data type. The example I linked to above, shows the kind of stuff we're doing.
PB must have something going for it if, after 50 years of programming, I choose to work with it rather than anything else.
I evaluated REALBasic several years ago as well and came to the same conclusions: too buggy and a fat runtime.
Why not C++? Too much hassle?
What standard BASIC features have you found PB to be missing?
Re: Borrowing from Object Oriented systems
Posted: Tue Nov 26, 2013 8:03 am
by BorisTheOld
USCode wrote:Why not C++? Too much hassle?
What standard BASIC features have you found PB to be missing?
"C"-anything is too much hassle. In the 1960s I cut my teeth on languages like Assembler, APL, FORTRAN, ALGOL, COBOL, PL/I, and the original Dartmouth time-shared BASIC. I could never quite get my head around why people would want to program in a "toy" language.
As for what's missing in PB: a full set of signed and unsigned data types, from 8 bit to 64 bit, including Currency; OLE strings; Format functions for all data types, not just date; ByRef support for all data types; a Mid statement; etc. In other words, the core features that most modern BASICs have.
This isn't a big problem though. We just code our own versions, where necessary, to fill the gaps.
Re: Borrowing from Object Oriented systems
Posted: Tue Nov 26, 2013 1:53 pm
by USCode
BorisTheOld wrote:
As for what's missing in PB: a full set of signed and unsigned data types, from 8 bit to 64 bit, including Currency; OLE strings; Format functions for all data types, not just date; ByRef support for all data types; a Mid statement; etc. In other words, the core features that most modern BASICs have.
This isn't a big problem though. We just code our own versions, where necessary, to fill the gaps.
Formal Pass by Reference support is definitely something I too would like to see.
Is this the type of Mid statement you are referring to, or something else?
http://www.purebasic.com/documentation/string/mid.html
Re: Borrowing from Object Oriented systems
Posted: Tue Nov 26, 2013 2:19 pm
by IdeasVacuum
I don't give them a choice.
Exactly my approach. Only ever discuss the requirements of the software, that is what is important. If I buy some furniture, I never ask the supplier what make of tools he used..... OK, there are occasions when I use C/C++ because at the end of the project, the customer assumes ownership of the code and they want it in the same language as their other stuff, which is fair enough. I also do work for a CAD system that is coded in C/C++ and it is less hassle to work with the API in the same language.
Re: Borrowing from Object Oriented systems
Posted: Tue Nov 26, 2013 4:19 pm
by Demivec
I think he is referring to
this.
Re: Borrowing from Object Oriented systems
Posted: Tue Nov 26, 2013 4:55 pm
by BorisTheOld
Demivec wrote:
I think he is referring to
this.
Correct.
The Mid statement is needed just as much as the Mid function. And it's quite a different animal from ReplaceString.
The following link explains how we get around the problem using macros.
http://www.purebasic.fr/english/viewtop ... 40&t=57197
So instead of coding:
Code: Select all
Mid(String1, Position, Length) = String2
we would use:
Code: Select all
MidSet(String1, Position, Length, String2)
Re: Borrowing from Object Oriented systems
Posted: Tue Nov 26, 2013 5:35 pm
by USCode
IdeasVacuum wrote:... If I buy some furniture, I never ask the supplier what make of tools he used...
No, but you do ask what KIND of wood is used in the furniture ... e.g. Balsa vs Oak ...
Re: Borrowing from Object Oriented systems
Posted: Thu Nov 28, 2013 12:01 pm
by Danilo
@AndrewM:
Just found this by accident in Apple's developer docs:
Object-Oriented Programming
(part of
Object-Oriented Programming with Objective-C)
I think this article explains it very well to people that don't know what OOP is good for.
Re: Borrowing from Object Oriented systems
Posted: Fri Nov 29, 2013 12:44 pm
by AndrewM
Thanks Danilo,
It is a big article and I will mull it over for a few days.