| |
|
|
Jörg Sellmeyer | Wie wäre es, wenn das etwas umgestellt wird und mit (wahrscheinlich/hoffentlich) wenig Aufwand viele neue Möglichkeiten geschaffen werden und gleichzeitig wieder Funktionstokens (oder wie das heißt) frei werden. Es gäbe zukünftig nur noch MoveListTo(...) und MoveHandleTo(...). Wobei man auch das noch nur auf MoveHandleTo(...) reduzieren könnte. Das sähe dann so aus:
Analog dazu:
So hätte man nur noch zwei Containerfunktionen. Man könnte eben auch MoveListTo(...) ersetzen, indem bei MoveHandleTo(...) auch die Null als Parameter für die interne Liste benutzt werden kann. In dem Zusammenhang möchte ich nochmal erwähnen, dass ich es super fände, wenn diese Strings nicht in "" stehen müßten. Das Gleiche gilt für die ganzen Create(...)-Funktionen. |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 25.04.2012 ▲ |
|
|
|
|
Jörg Sellmeyer | Naja - dann sind allerdings noch nicht die MoveStrToList und MoveArrToList berücksichtigt. Vielleicht würde es schon viel bringen, wenn man diese direkt auf Listboxen o.ä. anwenden könnte ohne den Umweg über die interne Liste. |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 25.04.2012 ▲ |
|
|
|
|
| Es gäbe ja keinen ID-Mangel wenn mit einem einfachen Präkompilierer- Pass Funktionen wie folgt umgewandelt würden:
funktionsname(... f(1,...
MoveStrToList(... f(2,...
MoveArrToList(... f(3,...
Danach wäre es unnötigt bis schade Funktionsnamen zweckfremder zu benennen. |
|
|
| |
|
|
|
RGH | In X3 gehe ich noch einen Schritt weiter und fasse alle zu Move() zusammen! |
|
|
| XProfan X2Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 25.09.2014 ▲ |
|
|
|