Hmm ich glaub ich hab vorhin vergessen Absenden zu klicken ;)
Also nochmal ich wünsche mir Methoden in Types:
TYPE moop
a
b$
METHODE Create()
_list = NEW List
ENDMETHODE
METHODE Add()
ADDLAST(List,_list)
ENDMETHODE
ENDTYPEaufrufen dann mit moop.Create() oder moop:Create().
na wir wär das?
Hä!? Ich hab geantwortet:
Nein, weil das für den GPC so unglaublich viel Stress bedeuten würde. Ausserdem finde ich:
TYPE moop:
ENDTYPE
FUNCTION MoopCreate: m AS moop:
ENDFUNCTION
auch nicht komplizierter. Und Vererbung wird es eh nie geben. Da tick ich voll aus.
Danke Gernot!
Damit erleichterst du den "Prozedurialen" das Leben ungemein!!! ;)
Aber Vererbung ist doch sooo ein einfaches thema ;)
Nunja egal war ja nurn vorschlag hehe
QuoteAber Vererbung ist doch sooo ein einfaches thema
was nützt es das wenn es einfach ist, aber saumässig viele ressoursen kostet.
kostet nur erbschaftssteuer, also lassen wir das.
mfg
Ich bin gegen Methoden in den Arten, seinen ein Schritt in Richtung zu programmierendem OO, das in grundlegendem ein Niveau der Kompliziertheit hinzufügt, das weg vom Puting zum kompletten Anfänger sein kann. Betrachten Sie BlitMax, sein so gutes wie weg von der beträchtlichen BlitzBasic Gemeinschaft getötet, die für meinen Deutschen traurig ist.
@bigsofty: Häää? Nach zweimaligen Lesen hab ich den text noch immer nich verstanden ;) aber ich weiß was du sagen willst.
EDIT:// Google übersetzung ist böööööse ;)
Ich glaub er wollte sagen:
1. Er ist dagegen, in Richtung OOP zu gehen, weil das zu BASIC zusätzliche Schwierigkeiten hinzufügt. Das könnte Anfanger von GLBasic wegziehen.
Beipsiel BMax: scheint alle deutschen Entwickler von Blitz abgeschreckt zu haben.
.. oder so :D
Das problem gerade bei der spieleprogrammierung ist es das oop ein sehr hilfreiches mittel ist. Klar es ist zwar nicht so einfach aber ein kompromiss könnte man schaffen. ich weiß nich ob du die types mit structs oder mit classen machst. mit classen da würde es gar nich so schwer sein den kram umzusetzen.
nunja nevermind.
schranzi - bitte tread schließen ;)
Hier der Nachtrag aus Gernots Antwort aus dem Englischen Forum :D
Trucidare du Schlawiner du :D
Quote from: GernotOh no!. Hast Du eine Ahnung, wie viel Arbeit das inerhalb meines GPC bedeutet? Ich find's auch nicht soo wichtig, weil:
TYPE TAuto
METHOD Hupen:
ENDMENTHOD
ENDTYPE
oder:
FUNCTION Hupen: A AS TAuto
ENDFUNCTION
eigenltich nur anderer Stil ist, oder?
Und Vererbung... vergiss es
Andere Thema würde gelöscht...
Ahh nun weiß ich wo mein erster Thread abgeblieben ist ;) hab schon gedacht ich bin nich ganz fit im kopf.
Hätte da nen anderen Vorschlag :D
Mit Funktionen:
normal gehts so:
TYPE test
X
Y
res
ENDTYPE
LOCAL tests[] AS test
LOCAL t AS test
t.X = 10
t.Y = 20
t.res = Add(t.X,t.Y)
DIMPUSH tests[],t
WHILE TRUE
FOREACH t IN tests[]
PRINT t.res,10,10
NEXT
SHOWSCREEN
WEND
END
FUNCTION Add: x, y
LOCAL res
res = x+y
RETURN res
ENDFUNCTIONMein Vorschlag wäre:
TYPE test
X
Y
res = Add(X,Y)
ENDTYPE
LOCAL tests[] AS test
LOCAL t AS test
t.X = 10
t.Y = 20
DIMPUSH tests[],t
WHILE TRUE
FOREACH t IN tests[]
PRINT t.res,10,10
NEXT
SHOWSCREEN
WEND
END
FUNCTION Add: x, y
LOCAL res
res = x+y
RETURN res
ENDFUNCTION
Mein Deutscher saugt grosse Zeit! :D
Pls post in english, thats terrible :D
Hehe, ah well, I tried! ;)
Basically, I'm personally against OO being added to GLB. I saw the vast BlitzBasic community get OO added to their language (BlitzMax) and it destroyed said community. The average hobbiest programmer wants something simple to read, quick to implement and understand, esp. at the beginner stage, OO added a level of complexity to BlitzBasic that was off-putting to the point that a lot of the community simply left for a simpler life in other basics.
As I've said, this is just my personal experiences.
Now, Im off to read up on my German! :P
If you add OO to BASIC, what's the difference to C++/Java/.NET?
#define begin {
#define end }that's all!
Und was sagste zu meinen Vorschlag?
Machbar oder auch Mist :D
Hmm irgendwie regen sich alle nur darüber auf :(
Dabei wollt ich doch nur die Übersichtlichkeit verbessern...
Keiner hat gesagt das OOP in GLB implimentiert werden soll. Lediglich die Methoden wären der übersichts halber angebracht.
Schranzor mach zu datt ding hier...
Nö :D
ein grösserer lichtblick in sachen "inline" möchte ich bevorzugen, damt kann man einige dinge auf die sprünge helfen. also mehr offenen "inline" im zustätzlichen "inline-verzeichnis"von gernot für die user zum einbinden.
Was? Wie? Mehr INLINE Beispiele bei der Installation?
Habs auch net verstanden o.O
QuoteWas? Wie? Mehr INLINE Beispiele bei der Installation?
jach , damit der c++schleier langsam geöffnet wird für weitere befehle, dann bräuchte man nicht immer öfter ein geändertes glbasic rausbringen. module...module...module.
videocapture im gl-fenster,oh das wär etwas.
mfg
programmeir doch module -.-
ich hab schon ein lua modul und ein sqlite und ein zlib modul.
einfaches c++. der compiler ist gcc.
such bei google nach tuts.
beginnen mit
FUNCTION foo:
ENDFUNCTION
INLINE
ENDINLINE
Quote from: trucidareHmm irgendwie regen sich alle nur darüber auf :(
Dabei wollt ich doch nur die Übersichtlichkeit verbessern...
Keiner hat gesagt das OOP in GLB implimentiert werden soll. Lediglich die Methoden wären der übersichts halber angebracht.
Ne, ich nicht :)
Ich finde die Idee sehr gut, das ist ansich auch etwas was mir an BM gut gefallen hat.
Nur wollten die hier wahrscheinlich ne Eierlegendewollmilchsau erschaffen.
FUNCTION foo:
ENDFUNCTIONwarum beginnt das immer mit der leer-funktion , bevor der inline-code anfängt?
Wenn der Code in der Haupt-Datei steht, dann ist ein INLINE immernoch innerhalb der "main" Funktion.
Also, wenn ich globale Sachen deklariere, muss ich erstmal die main schließen. Das macht man i.d.R., indem man einfach eine eigene Datei dafür hernimmt. Meine Mini-Beispiele laufen aber in einer Datei, also mach ich vorher immer FUNCTION foo: ENDFUNCTION. Damit bin ich unterhalb von ENDFUNCTION im globalen Raum des namespaces __GLBASIC__.
Den muss man (wenn man z.B. was ganz globales ansprechen will) mit "}" zumachen, und später wieder mit "namespace __GLBASIC__ {" aufmachen.
ich habe jetzt mal etaws gefunden, ein kleines c++ tut.
wie kann man dieses als beispiel in glbasic - inline reinsetzen?
mfg
using namespace std;
int main()
{
cout<<"Bitte geben Sie eine Zahl ein\n";
int a;
cin>>a;
cout<<"Bitte geben Sie noch eine Zahl ein\n";
int b;
cin>>b;
if(a==b)
{
cout<<"Beide Zahlen sind gleich";
}
if(a {
cout< }
if(a>b)
{
cout< }
cout<<"\n";
}
Also ich denke vorkauen ist nicht der bringer und testen kann ichs hier auch nich aber niomm mal den ansatz:
FUNCTION foo:
ENDFUNCTION
INLINE
}
int main() {
std::cout<<"moop"<
//weietrer Code
}
namespace __GLBASIC__ {
ENDINLINEich kann dir aber gleich schon sagen dass du von dem programm nichts erwarten solltest weils 1. keine ausgaben gibt und 2. ich glaube nich mal ein glbasic fenster aufgeht. INLINE sollte nur für sachen benutzt werden die man in funktionen packen kann, die man im glbasic code verwenden kann ansonsten hat es wweniger sinn etwas in c++ // INLINE zu schreiben.
std::cout gibt's nicht - muss man erst deklarieren. Ebenso std::endl und std::ostream operator<<(const char*) und std::ostream operator <<(char);
Was soll das werden? Du hast ja keine Konsole auf. (Wobei's dafür auch eine INLINE Lösung gäbe).
Trucidare hat Rect.
Nimm C++ nur da her, wo Du mit GLBasic echt steckenbleibst. GLBasic _ist_ schnell - erhoff' Dir durch INLINE keinen Turbo.
GLBasic ist Turbo ;)
Und um Text aus zu geben brauch man keine Console, da tuts das GLB-Fenster schon 1000x :P
QuoteUnd um Text aus zu geben brauch man keine Console, da tuts das GLB-Fenster schon 1000x
ich könnte mir vorstellen, von einem konsolenfenster die grafik im glbasic-fenster zu beeinflussen mit neuen daten.
ist doch schrottig
Quote from: bigsoftyHehe, ah well, I tried! ;)
Basically, I'm personally against OO being added to GLB. I saw the vast BlitzBasic community get OO added to their language (BlitzMax) and it destroyed said community. The average hobbiest programmer wants something simple to read, quick to implement and understand, esp. at the beginner stage, OO added a level of complexity to BlitzBasic that was off-putting to the point that a lot of the community simply left for a simpler life in other basics.
As I've said, this is just my personal experiences.
Now, Im off to read up on my German! :P
I've the opposite opinion. OOP is just a tool, and can help make things clearer and easier to program. OOP can get very involved for people new to it and be confusing I guess partly because it is different. However I think GL Basic could benefit from some OOP principles.
As for BMax, my impression is that it's not the move to OOP that has caused a problem for users moving over (as you can still code normal procedual style programs) it's more that the documentation is a little weak and that Mark has made it so close to C++ in design, it's no longer as accessible as a whole as Blitz Basic was.
I do agree that GL Basic should not change what it is. Afterall it is fun to program in and very quick to get going while performance is very good. It would not hurt though to have some OOP ideas as mentioned in this thread and others as the benefits are worthwhile. Simply being able to place in functions in to the types, which could then access it's typed variables as local variables, would be an excellent enhancement, and you can ofcourse ignore it and never use it if it worries you ;)
eg, simple TYPE that contains all the code and properties wrapped up in one place, makes it very easy to lift this up and re-use in any program you write:
TYPE tPrint
x;y
FUNCTION Print: message$
PRINT message$, x, y
ENDFUCNTION
ENDTYPE
GLOBAL myPrinter AS tPrint
myPrinter.x = 100;
myPrinter.y = 100;
myPrinter.Print("Hello World")I remember when Turbo Pascal went OOP many, many years ago it seemed very confusing and wondered what the benefit of it was over the convential procedural method we were so used to. Once you understand how you can make use of OOP, no matter at what level you use it, it can help you organise and think about solutions in a different and sometimes better way. It doesn't have to change how or what GLBasic is in the slightest. Just another tool in your toolbox. If only I could convince Gernot to add it. :)
I think it's not quite fitting GLBasic. Also, I fear for people screaming about inheritance and polymorphism (which really is a great tool - but not BASIC).
Anyway, my spare time is quite limited, too... ;)
To be fair, BASIC isn't BASIC anymore ;) VB.NET and other BASIC derived languages have evolved to include OOP for example. However I'm not meaning to pester you and I'm happy to make good use of TYPES in GLB. What do you mean your spare time is limited ? hehe ... Is it because we keep pestering you ? ;)
Nah ;) I'm just a bit busy with my life. And I also have some games I wanted to finish. GLBasic is really fun to work on, but there's times when I just want to write a game, too. I started a game for my little kid, and soon she will be too old for the game, but it's not done, yet :p
Well I agree with Gernot here, GLBasic is simple to use, fun and yet powerful enough to produce commercially viable games, this is something to be cherished in the word of computer languages.
BlitzMax found this out to its cost, if people wanted OOP, they'll go C++, its faster, the options for 3rd party support are infinite as is the existing code base... so why stick by a obscure new basic OO dialect that now has a steeper learning curve?
Any ways, Gernot I've a 4 year girl and my 1 day old girl (yep, Im a proud new father! :D), so make sure you do an English translation bud! ;)
Happy Birth-Day!!!!
Hehe, thanks Gernot :)
Congratulations Bigsofty!
Von, mir auch Glückwünsche :)
Dankt Freund! :D
Und von mir auch alles Gute und Schöne ;)
Allet Jute ;)
That kölsch(Colonge Germany) :D
Dank alle! :)
Kind words, well met!