If we ever get the ERS back, I hope it occupies a visible place on this forum and I think it would be a great idea for it to include a category for low hanging fruit ... stuff that can't possibly take much effort and which could be knocked off quickly by one of the new teams.
Today's candidate is getting rid of the 12 character limit on stream names. How ridiculous!!!
I have a couple:
1) not being able to specify a method as a response target for sockets
2) not having a high level ABL widget for sockets. (I know you can roll your own, but really ...)
3) no inter-process messaging
4) still having v9 installations in the wild **
5) (new SomeObject()):SomeMethod()
6) no write-json() or write-xml() on a table or table row (db, not temptable)
7) no write-json() or write-xml() on a class
8) having char and longchar. Longchar will do
9) only Progress.lang.object allowed in temp-tables
10) no enums
11) no dynamic array (keeping the contents)
I could go on ...
** Joking ...
Arrggh.
12) no regex
Stream names? Are you serious?
I'd have expected that YOU'd be wrapping each stream in an object of its own and then the actual stream identifier would be pointless...
In fact, the occassion for the remark is code that is unlikely to have any streams at all when it is done, having replaced what is now just being dumped to files so that I can see how it is working with putting stuff in a database. So, yeah, if there are streams in the end they will be well encapsulated. I still think a 12 character limit is ridiculous. Only paying attention to the first 12 would be bad enough, but not allowing the 13th character is just stupid.
Some of those might not qualify as low hanging ... but that doesn't mean they aren't desirable.
5) (new SomeObject()):SomeMethod()
What's the point here?
(NEW NewObjectSomeMethod.Foo ()):FooMethod ().
works fine on 10.2B and 11.0
the point is that it is stupid to have to require the extra ()
you should be able to say
new NewObjectSomeMethod.Foo ():FooMethod ().
at least then the editor would also give you intellisense and completion of methods / properties etc
tamhas wrote:
In fact, the occassion for the remark is code that is unlikely to have any streams at all when it is done, having replaced what is now just being dumped to files so that I can see how it is working with putting stuff in a database. So, yeah, if there are streams in the end they will be well encapsulated. I still think a 12 character limit is ridiculous. Only paying attention to the first 12 would be bad enough, but not allowing the 13th character is just stupid.
I do hope you're not serious
"Only paying attention to the first 12 would be bad enough,"
you would be happy for
AStreamNameXX
and
AStreamNameXY
to be treated the same if they were defined in the same procedure / class ?
I don't see any of these as hard to implement ...
the point is that it is stupid to have to require the extra ()
From previous discussions on extra parentesis or quotes with the developers, I've had to understand that those are notnecessary low hanging fruits. Did you ever wonder why you have to put the classname of an .NET object array or generic type into quotes?
If we ever get the ERS back, I hope it occupies a visible place on this forum and I think it would be a great idea for it to include a category for low hanging fruit ... stuff that can't possibly take much effort and which could be knocked off quickly by one of the new teams.
An ERS with an opportunity to vote for existing requests without the need to open a tech support case of its own when an existing enhancement request makes it (accidentially) into the PANS mail would be cool. And how difficult could that be to develop with all the cool products Progress Software has.
No. I did not say that I would be happy with 12 significant ... that is the road to danger as your example illustrates. I was simply saying that while 12 significant would be bad enough, not even allowing the 13th character makes it even more ridiculous.
If so, then fine ... but I wouldn't be surprised to find that some involved issues that were not that simple.
Possibly, with .net it's an issue.
however, in discussions with Shelly, this particular one was
classified as an "oops. We should fix that"
On 21 February 2012 20:01, Mike Fechner
If you have a limit of 12, then not allowing the 13th character makes
all the sense in the world to me. What am I missing ?
On 21 February 2012 20:03, Thomas Mercer-Hursh
the same reason why the KB moved to salesforce
On 21 February 2012 20:01, Mike Fechner
Well, it keeps one from shooting oneself in the foot ... but stupid either way.
In the specific case that triggered the post, 13 would have done and the first 12 were unique and I ended up having to use "Valu" instead of "Value" to get it to compile.
It is the sort of limit I expect from a 1980s BASIC.
640k ought to be enough for anyone
On 21 February 2012 20:16, Thomas Mercer-Hursh
new NewObjectSomeMethod.Foo ():FooMethod ().
This is a bug already (OE00195481).
-- peter
We *know* its a bug, Peter! The question is when will you fix it?
this is not a bug. This is an apple just about to be picked.
that's one removed from the LHF list
Vielen Dank für Ihre Nachricht! Ich werde ab Mo. 27.02. wieder im Büro sein und Ihre Email-Nachricht beantworten.
Mit freundlichen Grüssen - Josef Siegetsleitner, Easyrent Software Entwicklung
Thank you for your message! I will return to my office on Feb, 27th and will answer your email then.
Best regards - Josef Siegetsleitner - Easyrent Software Development
jmls wrote:
I have a couple:
11) no dynamic array (keeping the contents)
Technically, a couple is two , not 11 10 9.
On the dynamic array question: would a Progress.Lang.[Char|Int|Date|etc]Array object that does this suffice? Just curious .
-- peter
On the dynamic array question: would a Progress.Lang.[Char|Int|Date|etc]Array object that does this suffice?
Yes! (for me)
Give us more objects ... And a Progress.Lang.ObjectArray as well.
And once you've opened that box, a Progress.Lang.Array a generic, typesafe array would be handy.