1. Win32Lib RichEdit suggestion
- Posted by aku at inbox.as
Mar 24, 2001
Why I can't use getText for RichEdit, I must use getRichText.
It's better to use getText for RichEdit, but keep getRichText.
2. Re: Win32Lib RichEdit suggestion
Aku wrote:
> Why I can't use getText for RichEdit, I must use getRichText.
>
> It's better to use getText for RichEdit, but keep getRichText.
getText(id) does work for RichText already. It returns the *selected* text
from a RichEdit control. The getRichText(id,range) is used when you need to
get text other than what the user has selected.
Because they take different parameters, it would break existing code to make
getText work the same as getRichText.
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
3. Re: Win32Lib RichEdit suggestion
On 24 Mar 2001, at 13:09, Derek Parnell wrote:
>
>
> Aku wrote:
>
> > Why I can't use getText for RichEdit, I must use getRichText.
> >
> > It's better to use getText for RichEdit, but keep getRichText.
>
> getText(id) does work for RichText already. It returns the *selected* text
> from a RichEdit control. The getRichText(id,range) is used when you need to
> get
> text other than what the user has selected.
>
> Because they take different parameters, it would break existing code to make
> getText work the same as getRichText.
Even if you had it accept all the passed parms as a sequence or object, and
counted the number of parms to determine what the programmer intended?
function x(sequence data)
If (length(data) = 4) then -- they want this
elsif (length(data) = 3) then -- they want to do this
else abort(1,"wrong number of parms in function x!")
end if
Kat,
puzzled about this.
4. Re: Win32Lib RichEdit suggestion
Hi Kat,
> Even if you had it accept all the passed parms as a sequence or object,
and
> counted the number of parms to determine what the programmer intended?
>
> function x(sequence data)
> If (length(data) = 4) then -- they want this
> elsif (length(data) = 3) then -- they want to do this
> else abort(1,"wrong number of parms in function x!")
> end if
>
Of course you are correct in that it is technically possible. And I even
considered doing it that way. But for the sake of consistancy (and thus
predictablilty) it is probably better to have a parameter mean only one
thing. There are examples in win32lib where this is not strictly the case
and I'm not sure its a good thing.
To go to an extreme, we could define all routines with one parameter such as
..
procedure xxx(object params)
...
end procedure
and have the procedure parse the 'params' parameter to interpret and pull
out the real parameters. But is this a good thing. There will always be
cases where it is the better (or only) option available, but it doesn't make
it easier for the coder using the routine.
Another argument that supports your proposition is that its may not be a
good thing embedding data into the name of a routine. In our case,
getRichText() could be said to have the data "Rich" in the name, whereas
this could have been supplied in a parameter instead. In other words,
getText() could have been defined as getText(id, range) and if 'id' referred
to a RichText item, then 'range' would have been used in a different manner.
There is no hard and fast, right way to do these things. However, the
general prinicple I like to adhere to is that each named variable (and
parameter) should have only one meaning and purpose with its scope.
Now if I was going to make a suggestion for an enhancement Euphoria,
optional parameters might be nice.
function getText(integer id, optional sequence range)
if missing(range) then
range = {0,0}
end if
. . .
end function
so that coders could use either getText(myButton) or getText(myRT, {4, 17}).
And while we're at it, how about named parameters such as ...
theText = getText( range:={4,17} id:=myButton )
so that coders don't have to rememeber the order that parameters have to be
in.
But why wish for things we can't get, eh 
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
5. Re: Win32Lib RichEdit suggestion
>From: Derek Parnell <ddparnell at bigpond.com>
> Now if I was going to make a suggestion for an enhancement Euphoria,
> optional parameters might be nice.
>
> function getText(integer id, optional sequence range)
> if missing(range) then
> range = {0,0}
> end if
> . . .
> end function
>
> so that coders could use either getText(myButton) or getText(myRT, {4,
17}).
>
> And while we're at it, how about named parameters such as ...
> theText = getText( range:={4,17} id:=myButton )
> so that coders don't have to rememeber the order that parameters have to
be
> in.
>
> But why wish for things we can't get, eh
You can write a preprocessor and have all those things you want.
The problem of interpreter is that language syntax has to be simple, else it
will be slow. If Euphoria was compiler Robert sure wouldn't be so careful
about adding new features.
I would suggest this: add as many features to language as users want, and
with that make interpreter run slower. So interpreter would be used only for
debugging, so you don't have to wait for compilation, and for release
version of your program you would translate it to C.
