PureBasic Forums - English

Posted: **Sun Feb 03, 2013 11:15 pm**

PureBasic won't be object oriented, period.

Posted: **Sun Feb 03, 2013 11:28 pm**

Danilo wrote: Even C++ is simpler and cleaner.

A language supporting OOP natively can boast a simpler and cleaner syntax then using interfaces and explicit virtual tables in PB ?

I suspected as much.

Posted: **Mon Feb 04, 2013 2:11 am**

BorisTheOld wrote:Dare I say, once again, that PB already has everything one needs to create classes.

We use classes for every aspect of our applications. It's easy to do and creates well structured code.

The future is already here.

Here's an example. This class works with others to implement a menu structure in the form of a Tree gadget. It uses standard PB features and is cross-platform.

Hi Boris,

I must say your posts are always very interesting (even if sometimes a bit wordy !!)

1. Could you recommend a good generic book on programming with classes - or do you just have to understand a language that uses classes and then implement this in PB?

2. What type of application are you actually writing ?? Do you have a web page with examples ??

Thanks,

Posted: **Mon Feb 04, 2013 3:54 am**

Fred wrote:PureBasic won't be object oriented, period.

It is more interesting how many years we still have
until the module-concept.

@Neil
Before using a paradigm like OOP (and classes), you
should always learn how it works and what it is for.

MFG PMV

Posted: **Mon Feb 04, 2013 7:10 am**

We go round and round...

I vote for procedures in structures

Then they are insulated and private until the structure is used.

Posted: **Mon Feb 04, 2013 7:37 am**

People emphasize too much on classes and forget that classes come at a cost, especially if you mix stuff like multiple inheritance into the mix.
There are other ways to get modular programming going. (without the complexity...)

@Fred
Maybe we can get this instead:
(similar to the Go language - it has no "classy" oop either)

Code: Select all

Module MyMod

Structure Foo
    intFoo.i
EndStructure

Procedure.i (x.Foo) Get()
        ProcedureReturn x\intFoo
EndProcedure

Procedure (x.Foo) Set(value.i)
        x\intFoo = value
EndProcedure

;- main
Global myfoo.Foo 
myfoo\Set(123)
PrintN(Str(myfoo\Get()))

Where the "(x.Foo)" is the receiver of the procedure.

In the long run this is much more flexible and maybe even more powerful than the "class" thing.
Especially if each include file is a module and therefore each module can have procedures with the same name.

Posted: **Mon Feb 04, 2013 7:48 am**

Fred wrote:PureBasic won't be object oriented, period.

Fred, let it be, not OOP, but need of isolation procedures (procedures available from a limited part of the code). Otherwise difficult to develop and support projects. I hope you agree with this?
This can be a Name Space and (or) procedures within the structure.

Especially if each include file is a module and therefore each module can have procedures with the same name.

+1000000

Posted: **Mon Feb 04, 2013 12:11 pm**

Namespaces (modules) are planned for code isolation, but it won't be OOP.

Posted: **Mon Feb 04, 2013 12:58 pm**

Fred wrote:Namespaces (modules) are planned for code isolation, but it won't be OOP.

How is it planned?

Code: Select all

Module GUI
   Procedure OpenWindow(..)
   EndProcedure
EndModule

GUI\OpenWindow(...)
GUI->OpenWindow(...)
GUI_OpenWindow(...)
GUI#OpenWindow(...)
GUI?OpenWindow(...)
GUI::OpenWindow(...)

Posted: **Mon Feb 04, 2013 1:24 pm**

Like that:

GUI_OpenWindow(...)

With an OpenModule/CloseModule to avoid the prefix if you want to.

Posted: **Mon Feb 04, 2013 1:30 pm**

Fred wrote:Like that:

GUI_OpenWindow(...)

With an OpenModule/CloseModule to avoid the prefix if you want to.

Like this?

Code: Select all

Module GUI
   Procedure OpenWindow(..)
   EndProcedure
EndModule

GUI_OpenWindow(...)

OpenModule GUI

    OpenWindow(...)

CloseModule

Sounds OK, but how is OpenWindow() within OpenModule/CloseModule differentiated from the real PB OpenWindow()? (name collision)

Posted: **Mon Feb 04, 2013 2:06 pm**

It will raise an error if your command name clash (like an user lib), so you will have to use the module prefix.

Posted: **Mon Feb 04, 2013 2:11 pm**

Code: Select all

GUI_OpenWindow()

How do you know looking at the call you are invoking OpenWindow() in the module GUI and not a procedure named GUI_OpenWindow() ? After all GUI_OpenWindow is a valid name.

Wouldn't be better to use as separator something currently invalid in a procedure name ? For example GUI::OpenWindow()

Code: Select all

Module GUI
   Procedure OpenWindow(..)
   EndProcedure
EndModule

GUI::OpenWindow(...)  ; call the one defined in the module GUI

OpenModule GUI
 OpenWindow(...)  ; call the one defined in the module GUI
CloseModule

OpenModule GUI
 Other::OpenWindow(...) ; call another OpenWindow from another module

 ::OpenWindow(...) ; call the implicit module (the only one we have now) hence call the PB OpenWindow

 OpenWindow(...) ; call the one defined in the module GUI

 OpenScreenWindow(...) ; not defined in the module, call the PB command
CloseModule

Fred wrote:It will raise an error if your command name clash (like an user lib), so you will have to use the module prefix.

Shouldn't be the purpose of modules to avoid the name clashing in the first place ?

Shouldn't work the other way around then ?

If I use OpenModule all the procedures I call should be searched in that module first without any collision. If it's defined, I call that one.

If a procedure I call is not defined in the module, then the compiler should look outside the module, that way it would find the usual PB commands.

In case I know I want to call a procedure outside the module that has the same name of one in the module, I should have to specify the target module name in the call or the default "implicit" one using only the special chars "::".

Am I missing something ?

Posted: **Mon Feb 04, 2013 2:15 pm**

Maybe better to do so?

Code: Select all

Module GUI Extends Wind ; Inheritance module Wind.

Public ; Exported from the module.

   Pos.POINT

   Procedure OpenWindow(..)
   EndProcedure
   
Private ; No exported from the module.

   Structure MyStruct
     x.l
   EndStructure

   Win.RECT

   Procedure WindowParam(..)
   EndProcedure
   
EndModule


x.MyStruct ; Error - Private Structure.

OpenModule GUI

  Pos\x=0 ; OK.

  OpenWindow(..) ; OK
  
  Win\left = 4 ; Error - Private Structure
  
  WindowParam(..) ; Error - Private Procedure.
  
  x.MyStruct ; Error - Private Structure.

CloseModule

Should support nested calls modules.

Code: Select all

Module GUI

   Procedure OpenWindow(..)
   EndProcedure

EndModule
   
Module Event

   Procedure EventWindow(..)
   EndProcedure

EndModule


OpenModule GUI
  
  OpenWindow(..)

  OpenModule Event

     EventWindow(..)

  CloseModule ; Close Event (default)

CloseModule

Code: Select all

OpenModule GUI
  
  OpenWindow(..)

  OpenModule Event

     EventWindow(..)

  CloseModule GUI

CloseModule Event

Posted: **Mon Feb 04, 2013 2:59 pm**

Fred wrote:It will raise an error if your command name clash (like an user lib), so you will have to use the module prefix.

Thanks!

Sounds OK, except that "Using Module Danilo" or just "Using Danilo" would be easier to use for end users (that use my inckude)
than "OpenModule Danilo" / "CloseMdule" combination.

Code: Select all

Module Danilo
   Procedure New_Window(..)
   EndProcedure
EndModule

win1 = Danilo_New_Window(...)

OpenModule Danilo

    win2 = New_Window(...)

CloseModule

Code: Select all

Module Danilo
   Procedure New_Window(..)
   EndProcedure
EndModule

win1 = Danilo_New_Window(...)


Using Module Danilo
; Using Danilo ; alternatively

win2 = New_Window(...)

Generally speaking it is just someting like With/EndWith?

PureBasic Forums - English

Classes in PureBasic

Re: Classes in PureBasic

Re: Classes in PureBasic

Re: Classes in PureBasic

Re: Classes in PureBasic

Re: Classes in PureBasic

Re: Classes in PureBasic

Re: Classes in PureBasic

Re: Classes in PureBasic

Re: Classes in PureBasic

Re: Classes in PureBasic

Re: Classes in PureBasic

Re: Classes in PureBasic

Re: Classes in PureBasic

Re: Classes in PureBasic

Re: Classes in PureBasic