Re: [fpc-devel] type discussion
Jamie McCracken wrote: Garbage collection is largely no issue when using the Owner concept in TComponent, using TObjectList, etc. True and thats why I suggested ref counting Tobjects only so that no manual memory management is required. I tend to make heavy use of TList, Tstringlist and TFilestream objects so I cant do everything with tcomponents alas. What do you mean with Tobjects? Isn't TObject the ancestor of all classes? If you mean a dedicated root class for reference counted objects, you can use interface instead of class variables (at least in Delphi, not sure about FPC). As was already pointed out, GC doesn't work well without assistance in actual code. There's no big difference between setting a reference to Nil, and calling the destructor or FreeAndNil, for the same purpose. Auto-destroyed local objects, or local interface references, require hidden try-finally blocks; from similar discussions I know that many people don't like such invisible magics, for performance and othX-Mozilla-Status: 0009 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Danny Milosavljevic wrote: you *might* have less overhead using ref count on a tstringlist then making it a component (if you are creating more than one reference to it or passing it as a parameter to a function then yes a component would be more efficient). You also have the problem of what you are going to set the owner to in the case where its only a temp variable. owner nil, and free later yeah and now you are back at manual management. ref cycles are not a big deal - show me one bit of the FCL that has cycles using Tobjects only (IE not with Tcomponents)! I dont know the fcl enough for that. But generally speaking, most (nice) trees have that problem actually. Good point but are trees like that the exception or the rule? I mean Delphi's TTreeview's TTreeNode is not cyclic AFAIK. however they are better implemented using Tcomponent where the parent objects can automatically free the children. In any case we would need weak refs to overcome problems like these in tobjects. so in your code we would have something like: b.Parent := weak (a); where weak() prevents the ref count from incrementing. Or a quick hack would be to manually dec the ref count (assuming we provide a public Tobject method for this) after that assignment. What we shouldn't do is rely on the developer who is using the class to nil it at the end cause that defeats the whole purpose. I admit its not perfect but exceptions like these should hopefully be few and far between. Its obvious that you wont have cycles in things like TstringList, TFileStream objects etc. In fact only in Tlist are you likely to have cycles and in the add method you could check to make sure no self references are added and throw an exception if they are. A knowledgable developer can of course set any object to nil if he knows that there are or likely to be cycles but again this will only happen in a very small minoirty of cases. For gui stuff, it like happens all the time... Absolutely, which is why components will not be ref counted for tree stuff, it like happens all the time ... hmm dunno - its hard to say how common occurances like your example are as all the trees I have recalled using have not been cyclic like that. I would implement ref count on TObjects with a protected boolean variable to turn it off for TComponent descendants as we dont need to ref count components and components by their nature are far more likely to have cycles then plain objects. Its also obvious that pascal by its nature is far better suited to efficient ref counting than others like java because java strings are objects and ref counting a whole load of short term objects can adversely affect performance. (imagine deleting a stringlist where all and pascal strings are ? records or pointers to records. If you use shortstrings then it will be fast cause they are not ref counted. Java strings by comparison are classes so they will always suck in this regard. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thursday 02 June 2005 13:04, Jamie McCracken wrote: However, in general Pascal has poor developer productivity when compared to modern languages like python and C#. In terms of _written_ or in terms of _working_ lines of code? :- Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Vinzent Hoefler wrote: On Thursday 02 June 2005 13:04, Jamie McCracken wrote: However, in general Pascal has poor developer productivity when compared to modern languages like python and C#. In terms of _written_ or in terms of _working_ lines of code? :- Dont kid yourself - a lot of my fellow Delphi programmers have dumped it for C# already so it is really worrying for me espcially with borland being virtually bankrupt. Delphi as it is faces a bleak future so its looking increasingly like its time to modernise or die. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thursday 02 June 2005 13:22, Jamie McCracken wrote: Vinzent Hoefler wrote: On Thursday 02 June 2005 13:04, Jamie McCracken wrote: However, in general Pascal has poor developer productivity when compared to modern languages like python and C#. In terms of _written_ or in terms of _working_ lines of code? :- Dont kid yourself - a lot of my fellow Delphi programmers have dumped it for C# already so it is really worrying for me espcially with borland being virtually bankrupt. Delphi as it is faces a bleak future so its looking increasingly like its time to modernise or die. Yeah. Flies. Shit. They keep telling me the same about Ada. Still, I am much more productive than any of my fellow programmers who are doing things in C, Java, or Python. While they are still debugging and chasing NullPointerExceptions and such stuff, I already implemented the next needed feature. I can't even remember when was the last time I actually needed a debugger. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thu, 02 Jun 2005 14:22:55 +0100 Jamie McCracken [EMAIL PROTECTED] wrote: In terms of _written_ or in terms of _working_ lines of code? :- Dont kid yourself - a lot of my fellow Delphi programmers have dumped it for C# already so it is really worrying for me espcially with borland C# is very much like delphi, not at all like Python. What were their reasons to switch ? Python is hard to read, especially if multiple blocks are closed at once, then it's hard to see what block a line belongs to (because of missing 'end' or '}'). I also don't like the magic. For example the 'mystrings.create;' example you mentioned, it's *totally* not consistent with regular syntax: mystrings.create means call TStringList.Create on the object pointed to by the mystrings variable. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Vinzent Hoefler wrote: On Thursday 02 June 2005 13:04, Jamie McCracken wrote: However, in general Pascal has poor developer productivity when compared to modern languages like python and C#. In terms of _written_ or in terms of _working_ lines of code? :- Both in fact as they are directly correlated. The studies show that in high level languages (C nothwithstanding) there is very evident but simple correlation -- number of programmer errors per language construct (typically in not obfuscated code it's very close to the number of not empty non comment source lines) is independent of the language. But languages do differ significantly wrt. how many constructs are required to solve particular programming problems. C++ (pre stl) was worst there, Python, Perl likes were the best, Java was not that bad but still about 30% worse thatn Python (C++ was 100% i.e 2x worse). The biggest boost to effectivanes was bring by introducing automated memory management (i.e. getting rid of explicit memory freeing). So even languages with ugly C-ish syntax like Perl the awful can beat otherwise elegant clean languages. Hence probably the greaytest impact on Objective Pascal productioveness would come from allowing programmers to declare classes like self managing (self freeing, not needeing explicit destructions). rgds -- Sebastian Kaliszewski ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Micha Nelissen wrote: On Thu, 02 Jun 2005 14:22:55 +0100 Jamie McCracken [EMAIL PROTECTED] wrote: In terms of _written_ or in terms of _working_ lines of code? :- Dont kid yourself - a lot of my fellow Delphi programmers have dumped it for C# already so it is really worrying for me espcially with borland C# is very much like delphi, not at all like Python. What were their reasons to switch ? Because its so close to Delphi and they have switched because they found it more productive. No forward declarations, garbage collection and a richer framework has made them switch to the dark side. We need to fight back! Python is hard to read, especially if multiple blocks are closed at once, then it's hard to see what block a line belongs to (because of missing 'end' or '}'). not true because of the indenting (use bigger indents!). Im not saying python is great I just envy *some* of its shorter syntax and it would be so cool if Delphi/pascal did likewise - we could blow all these inferior languages away. I also don't like the magic. For example the 'mystrings.create;' example you mentioned, it's *totally* not consistent with regular syntax: mystrings.create means call TStringList.Create on the object pointed to by the mystrings variable. Well pascal in the only mainstream langugae that does that - I dont see the pont and it aint magic. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thu, 02 Jun 2005 14:52:13 +0100 Jamie McCracken [EMAIL PROTECTED] wrote: C# is very much like delphi, not at all like Python. What were their reasons to switch ? Because its so close to Delphi and they have switched because they found it more productive. No forward declarations, garbage collection I don't understand, why are these forward declarations so evil ? Garbage collection is largely no issue when using the Owner concept in TComponent, using TObjectList, etc. and a richer framework has made them switch to the dark side. We need to fight back! Ok, but richer framework simply needs people adding packages and useful units to freepascal :-). Python is hard to read, especially if multiple blocks are closed at once, then it's hard to see what block a line belongs to (because of missing 'end' or '}'). not true because of the indenting (use bigger indents!). Im not saying Bigger indents cause the text to go too wide. More functions also help, I agree. python is great I just envy *some* of its shorter syntax and it would Ok, some, but not this one ? I also don't like the magic. For example the 'mystrings.create;' example you mentioned, it's *totally* not consistent with regular syntax: mystrings.create means call TStringList.Create on the object pointed to by the mystrings variable. Well pascal in the only mainstream langugae that does that - I dont see the pont and it aint magic. Sorry, the only language that does what ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Micha Nelissen wrote: I don't understand, why are these forward declarations so evil ? More code bloat, more typing and they get in the way. They dont give me anything useful in return. Garbage collection is largely no issue when using the Owner concept in TComponent, using TObjectList, etc. True and thats why I suggested ref counting Tobjects only so that no manual memory management is required. I tend to make heavy use of TList, Tstringlist and TFilestream objects so I cant do everything with tcomponents alas. and a richer framework has made them switch to the dark side. We need to fight back! Ok, but richer framework simply needs people adding packages and useful units to freepascal :-). Python is hard to read, especially if multiple blocks are closed at once, then it's hard to see what block a line belongs to (because of missing 'end' or '}'). not true because of the indenting (use bigger indents!). Im not saying Bigger indents cause the text to go too wide. More functions also help, I agree. python is great I just envy *some* of its shorter syntax and it would Ok, some, but not this one ? Well typing begin..end all over the place isn't a lot of fun :( Especially as Im gonna have to indent them as well just to make em readable. So yeah it seems they are more pointless syntax bloat. I also don't like the magic. For example the 'mystrings.create;' example you mentioned, it's *totally* not consistent with regular syntax: mystrings.create means call TStringList.Create on the object pointed to by the mystrings variable. Well pascal in the only mainstream langugae that does that - I dont see the pont and it aint magic. Sorry, the only language that does what ? var strlist : TStringlist; strlist := Tstringlist.create; I know strlist is a Tstringlist, the compiler knows it too as I have declared it so why do I have to spell it out in the creation process? jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thu, 02 Jun 2005 15:31:51 +0100 Jamie McCracken [EMAIL PROTECTED] wrote: Micha Nelissen wrote: I don't understand, why are these forward declarations so evil ? More code bloat, more typing and they get in the way. They dont give me anything useful in return. Please show me a piece of code where they are in the way. Code bloat? They don't cost anything in the executable. python is great I just envy *some* of its shorter syntax and it would Ok, some, but not this one ? Well typing begin..end all over the place isn't a lot of fun :( Have you done maintenance yet of other people's code ? Especially as Im gonna have to indent them as well just to make em readable. So yeah it seems they are more pointless syntax bloat. They are not pointless to me: they indicate clear structure, but we may simply differ in opinion here. Sorry, the only language that does what ? var strlist : TStringlist; strlist := Tstringlist.create; I know strlist is a Tstringlist, the compiler knows it too as I have declared it so why do I have to spell it out in the creation process? In C++: TStringList strlist; strlist = new TStringList; How is that shorter ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Micha Nelissen wrote: On Thu, 02 Jun 2005 15:31:51 +0100 Jamie McCracken [EMAIL PROTECTED] wrote: Micha Nelissen wrote: I don't understand, why are these forward declarations so evil ? More code bloat, more typing and they get in the way. They dont give me anything useful in return. Please show me a piece of code where they are in the way. Code bloat? They don't cost anything in the executable. thats not what I meant! I mean its source code bloat to me especially when trying to follow code with large classes in it. python is great I just envy *some* of its shorter syntax and it would Ok, some, but not this one ? Well typing begin..end all over the place isn't a lot of fun :( Have you done maintenance yet of other people's code ? Especially as Im gonna have to indent them as well just to make em readable. So yeah it seems they are more pointless syntax bloat. They are not pointless to me: they indicate clear structure, but we may simply differ in opinion here. But its the indenting that gives the structure. If i used begin end blocks without indenting there would be no clear structure - it would be a mess! Sorry, the only language that does what ? var strlist : TStringlist; strlist := Tstringlist.create; I know strlist is a Tstringlist, the compiler knows it too as I have declared it so why do I have to spell it out in the creation process? In C++: TStringList strlist; strlist = new TStringList; How is that shorter ? okay but its still redundant. Why does the compiler need to have it spelt out twice? Why cant the compiler deduce that as the pointer is declared as TStringlist therefore it creates a TStringList? jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thu, 02 Jun 2005 15:54:54 +0200 Sebastian Kaliszewski [EMAIL PROTECTED] wrote: The studies show that in high level languages (C nothwithstanding) there is very evident but simple correlation -- number of programmer errors per language construct (typically in not obfuscated code it's very close to the number of not empty non comment source lines) is independent of the language. But languages do differ significantly wrt. how many constructs are required to solve particular programming problems. A correlation of things that are independent ? Then there is no correlation ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] type discussion
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jamie McCracken Sent: donderdag 2 juni 2005 16:32 var strlist : TStringlist; strlist := Tstringlist.create; I know strlist is a Tstringlist, the compiler knows it too as I have declared it so why do I have to spell it out in the creation process? What to do with virtual constructors or variables of a lower class ? ie. var strlist: TStrings; strlist := Tstringlist.create; or var strlist: TStrings; listclass: TStringsClass; listclass := TStringlist; strlist := listclass.create; Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Sorry, the only language that does what ? var strlist : TStringlist; strlist := Tstringlist.create; I know strlist is a Tstringlist, the compiler knows it too as I have declared it so why do I have to spell it out in the creation process? In C++: TStringList strlist; strlist = new TStringList; How is that shorter ? okay but its still redundant. Why does the compiler need to have it spelt out twice? Why cant the compiler deduce that as the pointer is declared as TStringlist therefore it creates a TStringList? Because the pointer might not be. Polymorphism, you know? :-) -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thursday 02 June 2005 15:16, Uberto Barbini wrote: If the goal is this, I'd prefear a way to declare objects autocreated: varauto: strlist: TStringList; begin //some stuff end; [...] It could be a problem to pass parameters to the constructor. Yes, exactly. So why bother the extra complexity? You still need the real thing, so for consistency it's better to stay with it only. Something like this you can see in Java: In the constructor of a derived class you always need to call the constructor of the base class in the first place. So, to simplify the task, the compiler does the magic for you, if there is a default constructor that has no parameters. Great. But the virtually same code just does not compile when there is no such thing as a parameterless constructor and you keep asking you why it does not f***ing compile. Until you read the 500 pages of the JLS and then *know* that the compiler does stupidly magic tricks for you. It can even become much more confusing if you have more than a single constructor. I don't think, this makes anything easier, less error-prone, whatever. It just confuses people. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Vinzent Hoefler wrote: On Thursday 02 June 2005 15:16, Uberto Barbini wrote: If the goal is this, I'd prefear a way to declare objects autocreated: varauto: strlist: TStringList; begin //some stuff end; [...] It could be a problem to pass parameters to the constructor. Yes, exactly. So why bother the extra complexity? You still need the real thing, so for consistency it's better to stay with it only. Thats why I proposed a month back in my modernising pascal thread to implement things like a stringlist as a base type container (like pyhton does with lists, dicts etc). This would then be dynamically allocated and ref counted. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Vinzent Hoefler wrote: On Thursday 02 June 2005 13:54, Sebastian Kaliszewski wrote: No, they aren't (or let me put it this way: It depends on what you measure). For instance, studies indicate that there are ten times more errors code in C code then in Ada code once you've delivered the software. If you didn't notice I wrote C nothwithstanding. C is far away from modern high level languages (and also many older than it but hight level languages). The studies show that in high level languages (C nothwithstanding) there is very evident but simple correlation -- number of programmer errors per language construct (typically in not obfuscated code it's very close to the number of not empty non comment source lines) is independent of the language. You must have read different studies. :) Certainly. Those I read were about mainsteream software development not niche life critical realitime systems. The study was measuring error rate in some typical and rather simple prgramming task coded in varius languages by varius programmers. Correlation found was clear -- number of bugs per 1kloc were constatant and independent of the language. The difference was that the same task could be coded in some languages using significantly lesser number of lines. A while ago Lockheed Martin switched to SPARK code (which is a statically proven version of Ada) and they claimed this saved them about 80% of development cost compared with former projects of the same size (and we're talking about a flight control system of five million lines of code here). Two things: 1. They'd better claim they got significant gains or someone should be fired for wasting money. IOW I take all such corporation made studies not with a grain but with a shuffle of salt. 2. You're talking about complex life-critical realtime system, not mainstream software. In such system the cost of bugs is many orders of magnitude higher than in mainstream. Cost structure of such projectes differs stronly from mainstream programming. C++ (pre stl) was worst there, Python, Perl likes were the best, Java was not that bad but still about 30% worse thatn Python (C++ was 100% i.e 2x worse). What did they actually measure? Which languages did they compare. The list above is all (except Python) more or less C-ish or even worse syntax. There was a bunch of popular languages (don't remember them all), C like were C++, Java Perl. Others certainly were not. The biggest boost to effectivanes was bring by introducing automated memory management (i.e. getting rid of explicit memory freeing). Which is something you definitely don't want in large scale realtime systems. But FPC is useless in such systems as well. Besides lack of convincing argumentation about compiler correctness, you need real time guarantees wrt allocations and other library stuff (which FPC does not provide). So even languages with ugly C-ish syntax like Perl the awful can beat otherwise elegant clean languages. Of course they can under certain circumstances. Just as a bubble sort can beat a quick sort algorithm if you feed the right input. If you'd use not the naive version of Qsort, but something more elaborate then you'd have to caerefully craft contrived input to cause it to work badly. But naive Qsort will work terribly on really common input. Those examples were real code not some contrived stuff. Hence probably the greaytest impact on Objective Pascal productioveness would come from allowing programmers to declare classes like self managing (self freeing, not needeing explicit destructions). Maybe, yes. But I'm old school. I like to handle memory myself. Well, I met some people who needed 'full controll' so they wnated to code in assembly. And I still need less than 2 MB while a Java VM is still loading its 100 MB foot print into memory. ;- Java is a different story, but GC overhead is not that bad in some better languages (2-3x). And performance seems to be unaffected: http://shootout.alioth.debian.org/benchmark.php?test=alllang=fpascallang2=ocamlsort=fullcpu Here comes Pascal (FPC) vs Ocaml (hybrid functional/imperative language with OO). Ocaml is significantly faster although it havily uses GC. Ocaml code is significantly shorter too (they can be coded in significanly lesser amount of lines). rgds -- Sebastian Kaliszewski ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thursday 02 June 2005 13:54, Sebastian Kaliszewski wrote: probably the greaytest impact on Objective Pascal productioveness would come from allowing programmers to declare classes like self managing (self freeing, not needeing explicit destructions). Maybe, yes. But I'm old school. I like to handle memory myself. And I still need less than 2 MB while a Java VM is still loading its 100 MB foot print into memory. ;- I think the time spent doing the manual compilation is overestimated, and the time problem solving in automatic allocation is underestimated. How many Java programmers routine set references to NIL ? Really a lot... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Marco van de Voort wrote: I think the time spent doing the manual compilation is overestimated, and the time problem solving in automatic allocation is underestimated. How many Java programmers routine set references to NIL ? Really a lot... This only shows the implementation (and std library design) is bad (and that's true at least to java 1.4) rgds -- Sebastian Kaliszewski ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
The difference was that the same task could be coded in some languages using significantly lesser number of lines. But that doesn't necessarily equal to less overall time. Also specially the size of the testing code pieces. The troubles typically only start when the program grows larger. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
This only shows the implementation (and std library design) is bad (and that's true at least to java 1.4) I hear this from nearly any language with automated allocation (C#, Python, Perl, Java). The concept is simple and attractive, the practice seems to be different. I'm not a grear fan of them, but managed objects are indeed very useful for modelling business applications. But they don't make sense for system classes, so all in all I'm against them. Some OPF like InstantObjects offer a kinda of them, and I think this is a good compromize. Bye Uberto ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
| More code bloat, more typing and they get in the way. They dont give me | anything useful in return. Why do you even bother using Pascal, it seems you obviously do not like one bit about it. | | | Garbage collection is largely no issue when using the Owner concept in TComponent, using TObjectList, etc. | | True and thats why I suggested ref counting Tobjects only so that no | manual memory management is required. I tend to make heavy use of TList, | Tstringlist and TFilestream objects so I cant do everything with | tcomponents alas. | | | and a richer framework has made them switch to the dark side. We need | to fight back! | | | Ok, but richer framework simply needs people adding packages and useful units to freepascal :-). | | | Python is hard to read, especially if multiple blocks are closed at | once, then it's hard to see what block a line belongs to (because of | missing 'end' or '}'). | | not true because of the indenting (use bigger indents!). Im not saying | | | Bigger indents cause the text to go too wide. More functions also help, I agree. | | | python is great I just envy *some* of its shorter syntax and it would | | | Ok, some, but not this one ? | | Well typing begin..end all over the place isn't a lot of fun :( Why do you even bother using Pascal, it seems you obviously do not like one bit about it. | | Especially as Im gonna have to indent them as well just to make em | readable. So yeah it seems they are more pointless syntax bloat. | Why do you even bother using Pascal, it seems you obviously do not like one bit about it. | | I also don't like the magic. For example the 'mystrings.create;' | example you mentioned, it's *totally* not consistent with regular | syntax: mystrings.create means call TStringList.Create on the | object pointed to by the mystrings variable. | | Well Pascal in the only mainstream langugae that does that - I dont | see the pont and it aint magic. | | | Sorry, the only language that does what ? | | var strlist : TStringlist; | strlist := Tstringlist.create; | | I know strlist is a Tstringlist, the compiler knows it too as I have | declared it so why do I have to spell it out in the creation process? Why do you even bother using Pascal, it seems you obviously do not like one bit about it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
| In C++: | | TStringList strlist; | | strlist = new TStringList; | | How is that shorter ? | | okay but its still redundant. Why does the compiler need to have it | spelt out twice? Why cant the compiler deduce that as the pointer is | declared as TStringlist therefore it creates a TStringList? | | Why can't I just go strlist = new Draw the line. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
the C-style operators += etc. should better be written as +:= since C has = as assignment, Pascal has := as assignment symbol := means assign to, += means add to etc., I cannot find any inconsistency here. Also, += and such were created to make it easier to convert C code. If you change this to +:= you do essentially two things: 1) Break existing code 2) Destroy any of the original purpose and usefulness of the thing in question. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Jamie McCracken wrote: I don't understand, why are these forward declarations so evil ? More code bloat, more typing and they get in the way. They dont give me anything useful in return. Please show me a piece of code where they are in the way. Code bloat? They don't cost anything in the executable. thats not what I meant! I mean its source code bloat to me especially when trying to follow code with large classes in it. I typically follow code by jumping to the definition of variables or subroutines, and back again. I rarely read source code sequentially, because the static arrangement of code pieces is different from their logical relationship. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Well pascal in the only mainstream langugae that does that - I dont see the pont and it aint magic. Jamie, now I KNOW I don't understand where you're coming from Pascal? Mainstream? ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
