Suppose I have the following class:

type
  TMyClass = class
  public
    property Caption: string read FCaption write FCaption;
    property Items[Index: Integer]: string read GetItem write SetItem;
default;
    function Count: Integer;
  end;

I would like to do this:

with MyClassInstance as mci, SomethingElse do begin
  Caption := 'A new caption';
  for i := 0 to Count - 1 do
    mci[i] := UpperCase(mci[i]);
end;

That is, to add an optional "as" clause to the with statement so that access array element in a structure is made easier.

default;

access array element in a structure is made easier.

This was already requested multiple times and also reported on the bugtracker... Nevertheless in your specific case you can just use "Items[i]" instead of "mci[i]".

Regards,
Sven

In my example, you can use Items[], but in my real project it is a record with

发送自魅族MX

-------- 原始邮件 --------
发件人：Sven Barth
时间：3月16日 17:12 周六
收件人：FPC-Pascal users discussions
主题：Re: [fpc-pascal] a proposal about "with" syntax

Sorry, the email was interrupted, but sent by the phone in background...

So the decision of this "feature" is that it is not worth to add, right?

Thanks.

2013/3/16 Xiangrong Fang

Hi,

I also think this would be useful, but for other reasons, often times I end up with code like the following:

With BigLongThingIDontWantToWriteOutEverySingleTime do
  begin
     Height := 100;
     Width := 200;
    ...
     SomeOtherObject.Submit(BigLongThingIDontWantToWriteOutEverySingleTime);
  end;

Notice how I have to write the long thing out again at the bottom. There must be a way around that (Something like "Self", but that refers to whatever you are using in With). In Xiangrong's example, this could be mci, but even it it was a static name it would be useful. (If this exists and I am just not aware, please let me know!)

Thank you,
Noah Silva

You can use a Class Helper:

http://pastebin.com/pFL49byh

But you gonna need to use a type cast. And with a "SomethingElse" at the with, as showed by Xiangrong, things can become messy.

shiruba 's example is better than mine, and
was exactly the reason I posted this suggestion.

I don't think a class helper is worth for this stuff, if I need to write a helper I would rather do this:

longobj := BigLongThingIDontWantToWriteOutEverySingleTime;
With longobj do begin
  Height := 100;
  Width := 200;
  ...
  SomeOtherObject.Submit(longobj);
end;

That's not elegant, but it is really not worth for a helper in this case, IMHO. "with" itself is a convenience syntax anyway, why adding an "as" to make it more convenient a bad idea? I don't know what's make it complex if there are 2 or more subject in the with?

2013/3/17 Daniel Gaspary

Xiangrong Fang wrote

I don't think a class helper is worth for this stuff, if I need to write a helper I would rather do this:

I am not sure that I understand your point.

The Class helper was a way to show how it's possible. And with that helper, ALL objects could use it's method. You could use it as library.

why adding an "as" to make it more convenient a bad idea?

I don't mean that. The Type cast is necessary in my solution, just that.

I don't know what's make it complex if there are 2 or more subject in the with?

Context. A conflict case the two object were of the same class.

Are you saying this case:

with MyClassInstance1 as m, MyClassInstance2 do begin
  m.Property1 := 123;
  Property2 := 456;
end;

Here you don't know Property2 belongs to which object instance?? If so, this is not a problem at all, because even without "as" you still cannot distinguish, so the compiler should deny this kind of usage anyway, however, with "as", you can do this:

with MyClassInstance1 as m1, MyClassInstance2 as m2 do begin
  m1.Property1 := 123;
  m2.Property2 := 456;
end;

To summarize, "as" does NOT try to eliminate context ambiguity (also it won't make a clear context ambiguous), but provided some convenience when needed.

No, he's saying that *his hack* using class helper wouldn't cover this case (two objects in the same 'with' clause).

Daniel, I find this hack as ingenious as atrocious ;-) But thinking about it a bit, when FPC gets generic methods you can make this kind of workable!

(...) To summarize, "as" does NOT try to eliminate context ambiguity (also it won't make a clear context ambiguous), but provided some convenience when needed.

As Sven said this feature has already been requested a few times. I don't remember whether it was permanently vetoed by FPC developers or just is in the to-do, but vaguely remember people arguing it's "un-pascal" because of the local variable/scope - which is unfortunate, because IMO the 'with' syntax is one of the most abominable un-pascal things Borland introduced in the language, and *forcing* the AS syntax (but probably with some other keyword like ALIAS) would make it much more palatable.

Best regards,
Flávio

Hi,

Also with using the "longobj" below, you have to declare it first (yet more manual temporary/helper variables). Also, once you do that, you don't need with as much to begin with since you could use a single char. variable name.

BTW, I don't think Daniel was suggesting that we actually use a class helper for such cases - just demonstrating that it's possible. I have to admit I didn't even think of using a class helper, so that's fairly creative. It could also be a possible implementation pathway if someone decides to implement it - but I doubt it since if you have access to internal compiler structures, you already know what "with" is referring to.

I am not sure anyone has decided that "as" is specifically a bad idea. (Correct me if I am wrong). Look at it the opposite way, though. For every request, there has to be somebody capable of implementing it in the compiler who has free time and considers it to be more important than all of the other things outstanding.

I fully support having an "as" operator or something effectively similar, however I also know than submitting a patch is better than making a feature request.

Also, I am happy just to have "with" at all. My "other" main language (ABAP) has lots of awesome stuff like Native DB integration, but somehow doesn't have WITH! (From the my limited Java experience, it seems Java doesn't have an easy alternative either).

Thank you,
Noah Silva

Hi,

Flávio Etrusco wrote

No, he's saying that *his hack* using class helper wouldn't cover this case (two objects in the same 'with' clause).

Well, more to the point, it only works with OOP. I use WITH on structures, etc. all the time, so ... yes implementing it in the compiler/RTL would be preferable of course.

Daniel, I find this hack as ingenious as atrocious ;-) But thinking about it a bit, when FPC gets generic methods you can make this kind of workable!

No comment, but the fact that he replied with his "solution" so quickly makes me wonder if he has actually used it before!

I'm a bit confused on this point. To me, WITH has been around for a long time, and is to me very Pascal. Probably because PAscal is one of the only languages that allows nested procedures, etc., and "with" seems similar to me. (Also, pretty much to me Borland = Pascal). Although I just wanted a keyword (like "self"), the AS proposal makes more sense if you use more than one item in the same WITH. (I usually don't because they would have the same fields anyway...)

I think having functions/procedures with no arguments callable with procedurename() is un-pascal-like as well, but it hardly bothers me that FPK allows it. Just because I don't love it doesn't mean others don't. (There is a lot of C like syntax that has creeped into FPK, but I assume that'S either because it was easy to implement and a few people wanted it, or because it made porting C stuff to Pascal easier). One could say OOP isn't Pascal like because the original inventor didn't come up with TObject...

Actually the only thing that makes me uncomfortable about the keyword "as", is that it strangely reminds me of SQL. I suppose that isn't a bad thing though.

Thank you,
Noah Silva

Actually the only thing that makes me uncomfortable about the keyword "as", is that it strangely reminds me of SQL. I suppose that isn't a bad thing though.

No problem with SQL, but "as" is already safe typecast, remember? ;-)

-Flávio

印場 乃亜 wrote

On 2013/03/17, at 11:37, Flávio Etrusco wrote: > Daniel, I find this hack as ingenious as atrocious ;-) > But thinking about it a bit, when FPC gets generic methods you can > make this kind of workable!

I was thinking about this, not specifically generic methods, but some new generic resource.

No comment, but the fact that he replied with his "solution" so quickly makes me wonder if he has actually used it before!

I never used it, but indeed I have thought before about a way to do this.

I would like to have option to use a kind of self in with statement, but I understand the compiler team that it is a superfluous resource.

Indeed. What I was thinking would actually need generic functions, bounded generics and generics with type-erasure ;-) So you'd write, say:

>>>

  type generic TAlias1<T: TObject> = class(TObject)
    function Alias1: T;
  end;
 function<T: TObject> Alias1(Source: T): TAlias1<T>;
<<<<

And yet you wouldn't be able to name the alias...

-Flávio

PS. I can't believe Embarcadero went for ":" instead of "=" for declaring bounded/restricted generics :-/

PS. I can't believe Embarcadero went for ":" instead of "=" for

declaring bounded/restricted generics :-/

That's correct, since : means "of type" in a declaration.

印場 乃亜 wrote

I think having functions/procedures with no arguments callable with procedurename() is un-pascal-like as well, but it hardly bothers me that FPK allows it. Just because I don't love it doesn't mean others don't. (There is a lot of C like syntax that has creeped into FPK, but I assume that'S either because it was easy to implement and a few people wanted it, or because it made porting C stuff to Pascal easier).

The reason that FPC allows to call parameterless functions and procedures with "()" is because Delphi (and maybe TP) allows it as well. For procedure/function variables (in non-Delphi modes) it is required however, because this way the compiler can know for sure that a procvar is called instead of just being used as a normal variable.

Regards,
Sven

This already works.

function<T: TObject> Alias1(Source: T): TAlias1<T>;

I don't really get what you want to express with that...

Regards,
Sven

Al 17/03/13 03:37, En/na Flávio Etrusco ha escrit:

unfortunate, because IMO the 'with' syntax is one of the most abominable un-pascal things Borland introduced in the language, and *forcing* the AS syntax (but probably with some other keyword like ALIAS) would make it much more palatable.

I checked on google books and it doesn't seem to be a Borland addition

http://books.google.es/books?hl=ca&id=mHSZRZnDp60C&q=with#search_anchor

Texas Instruments' Pascal had an extension of the with statement, IIRC it used = instead of AS

With a=VeryLongNameForARecord, b=AnotherRecordWithAVeryLongName do ...

Bye

Now THAT is really unpascalish... either ":=" or the already suggested
"as"...

Regards,
Sven

17.03.13, 18:25, Sven Barth пишет:

> With a=VeryLongNameForARecord, b=AnotherRecordWithAVeryLongName do ... Now THAT is really unpascalish... either ":=" or the already suggested "as"...

Why? Constants and Types are also use '=' instead of ':=' for assignments.

Best regards,
Paul Ishenin

[...] Now THAT is really unpascalish... either ":=" or the already suggested "as"...

The AS syntax bites already existing syntax.

Mattias

The AS syntax bites already existing syntax.

May I know what's the existing syntax?

> The AS syntax bites already existing syntax. May I know what's the existing syntax?

with A as T do

Mattias

Right. Then better ":=".

Regards,
Sven

But we aren't in a constant or type section here. Also one uses ":=" in
the for-loop header.

Regards,
Sven

In our previous episode, Sven Barth said:

disambiguate using the returnvalue of a function as function result, or calling that function recursively. IIRC TP couldn't use function result as rvalue.

Later it turned out that Delphi also allowed it.

In our previous episode, Sven Barth said:

Since it is a pseudo variable declaration, I would assume VAR syntax and just use ":" ?

Or maybe it should require a "variable" declaration (or otherwise declared identifier with fixed type).

Otherwise it goes into an undesirable direction:

Function Foo;
begin
   with a: SomeInteger do Work(a);
   with a: SomeBoolean do Work(a);
end;

a is first integer, then boolean within the same scope. *Very* confusing.

And very close to the next step (which of course can be rejected by the compiler)

Function Foo;
begin
   with a: SomeInteger do begin
      Work(a);
      with a: SomeBoolean do Work(a); // masking a
   end;
end;

But if the inner a was Integer too, then maybe it should work? Unless it gets a similar special status like a loop variable?

-------------------
IIRC in other threads on this topic, some people explicitly stated they wanted this feature so the would not need to declare "a" first (I may remember this wrong).
IMHO starting with the first loop hole of allowing an undeclared identifier to be used, is just opening the door to more and more weakening of the language requirement.
Besides, it does not hurt, if "a" needs to be declared.

Al 17/03/13 13:16, En/na Sven Barth ha escrit:

But, differently than a for-loop, it's not an assignment, it's just an alias definition.
Note that I can live without the option (after all I've not been using the TI compiler for more than 20 years), but I liked the syntax at the time and I still think it could be useful.

Bye

Al 17/03/13 13:54, En/na Marco van de Voort ha escrit:

That would be consistent with "On E:Exception do writeln(E.message)".

Bye

17.03.13, 20:16, Sven Barth пишет:

But we aren't in a constant or type section here. Also one uses ":=" in the for-loop header.

I agree that ':=' should be used but I would not say that '=' is not
pascalish :)

Let's look look at possibilities:

1. 'as' can't be used because we can use expressions in with and we can 'as' typecasting.
2. '=' can't be used because we can use expressions and '=' can be a part of expression. For example 'with DoSomething(a = b) do'.
3. ':=' can be used since we can't use assignments in with expressions.
4. ':' (Marco suggesion) can be used - it is not used in expressions. ':' is used in pascal to:
- separate variable and type,
- in write intristic
- in record constants to separate field and value
5. We can use some new keyword or reuse some keyword which is not used in expressions.

If I need to choose from 3, 4 and 5 I would use ':=' syntax because it
more like to assignment:
with a := TStringList.Create do
begin
   Text := 'bla';
   DoSomething(a);
   Free;
end;

Best regards,
Paul Ishenin

On 17/03/2013 12:54, Marco van de Voort wrote: > > Since it is a pseudo variable declaration, I would assume VAR syntax and > just use ":" ?

This is indeed better.

This is what already happens between the members of "aliased" variables, and that's IMO reason for the proposal. So I don't see a problem, on the contrary, it's progress since it needs a more direct/clearer user "error" to be bitten by it.

And very close to the next step (which of course can be rejected by the compiler)

It would be better.

I don't think so.

My POV is "with" already implies an undeclared variable.

Regards,
Flávio

No, because "On E: Exception" says that "E" is of the type "Exception", just like in a variable declaration the expression after the colon also identifies the type. Here it's not about defining the type, but about making a symbol equivalent to repeating a non-type expression. So "=" from symbolic constant declarations would probably be closest. I think ":=" is less good, because ":=" implies that a copy or an assignment is made rather than an equivalence is defined, and hence changes to that copy could be assumed lost afterwards in case of records or objects, which would not be the case.

Jonas

In 2.7 I assume, because it doesn't work in 2.6.2. Great anyway :)

> function<T: TObject> Alias1(Source: T): TAlias1<T>; I don't really get what you want to express with that...

This is a Java a construction, I don't know whether it exists in other languages.
In Java you specify it before the result type. It means the parameterized result is be based on the parameter it receives. You can also "bind" several parameters:

static <T extends Comparable> int IndexOf(List<T> p_list, T p_item);

-Flávio

Are there any reputable cases where both type and value need to be specified separately?

with foo: TSomeType= TSomeType(list.objects[i]) do

-- MarkMLl

Of course only 2.7.1 :P

So you're basically just talking about generic methods here? The Delphi compatible syntax for your two examples are:

=== code begin ===

function Alias1<T: TObject>(Source: T): TAlias1<T>;
function IndexOf<T: Comparable>(p_list: List<T>; p_item: T): LongInt;

=== code end ===

Support for generic methods (and global functions/procedures) is already planned. They will of course support generic constraints as well (it would be inconsistent if they wouldn't).

Regards,
Sven

Yes, I would prefer the ":=" as well because it's basically an assignment. OR (now it's getting crazy, especially with the example you gave ;) ):

=== code begin ===

with a absolute TStringList.Create do begin
   ...
end;

=== code end ===

Regards,
Sven

As I just wrote in another mail: what about "absolute". It might read strange at first with a more complicated expression on the right hand side, but it would express the concept of "this refers to the same".

Regards,
Sven

Yes. Or actually not, it also involves allowing
non-specialized/not-completely-defined variables.

This time I tried with 2.7.1 :)
But it also gives "Error: Generics without specialization cannot be used as a type for a variable".
Is something planned regarding this case?

Thanks a lot.

-Flávio

I am sorry I didn't follow this thread although I am the "OP" :-). If I understand correct, I would suggest NOT introduce the "absolute" keyword, instead, make it ALWAYS absolute. i.e.:

with a = SomeObject, b = SomeRecord do begin
  ... ...
end;

Both a and b are "reference" to the object or record, IMO there seems no need to do assignment in the with syntax. Thus, I suggest use = instead of :=

2013/3/18 Sven Barth

18.03.13, 9:27, Xiangrong Fang пишет:

'=' can't be used because it can be a part of expression. There is no big difference between
with (a = SomeObject) do
and
with a = SomeObject do

After more thinking I see that ':=' as well as absolute keyword are also
bad because they will complicate the parser (although it is possible to
use them). Parser will need to read the first token and check if it is
an identifier, read second token and compare with ':=' (or 'absolute')
and if it is not ':=' (or 'absolute') return to expression parse.

At the same time we will not complicate the parser if we place alias identifier after the with expression like:

with expression1, expression2 => alias2, expression3, expression4 => alias4 do

begin
end;

Where '=>' is some token which can't be used in expressions.

Best regards,
Paul Ishenin

OK, I see. However I feel "=>" a very "un-pascal" thing, remind me of PHP. :-) I guess "as" would also complicate the parser?

2013/3/18 Paul Ishenin

"Xiangrong Fang" wrote

OK, I see. However I feel "=>" a very "un-pascal" thing, remind me of

PHP. :-) I guess "as" would also complicate the parser?

As already written by others: "as" is one of the worst tokens you can choose for this, as it is perfectly legal to do a typecast in an expression (which includes the expression for with).

Regards,
Sven

18.03.13, 11:16, Xiangrong Fang пишет:

OK, I see. However I feel "=>" a very "un-pascal" thing, remind me of PHP. :-) I guess "as" would also complicate the parser?

I did not suggest to use '=>' I wrote

Where '=>' is some token which can't be used in expressions.

Which means replace '=>' in my example with some token (like ':' char or 'alias' word or anything else).

And since 'as' can be used in expressions (with List as TStringList do) we should not use it.

Best regards,
Paul Ishenin

Alternatively, how about just use SPACE to separate the token? i.e.:

with SomeObject o1, SomeOtherObject o2 do....

Because you need a COMMA for 2 or more expressions in with, and SPACE is not valid in token?

2013/3/18 Sven Barth

In our previous episode, Xiangrong Fang said:

Alternatively, how about just use SPACE to separate the token? i.e.: with SomeObject o1, SomeOtherObject o2 do....

That's perfectly fine for C. But this isn't C.

2013/3/18 Marco van de Voort

What's wrong here? In pascal, we also see space used in similar way:

property Item[Index: Integer]: Integer read GetItem write SetItem; default;

i.e. there is NO ; or anything before the "read" keyword, but you do need a ; before "default". Anyway, this maybe related to how the parser is implemented, or just a decision by the language designer, but I don't really see why this has to do with C vs. Pascal??

In our previous episode, Xiangrong Fang said:

Never between type and variable/alias name and never in the order type[space]variable

2013/3/18 Marco van de Voort

This is not the case, as the thing before space is NOT a type but a variable. In my feeling things un-pascal is extensive use of "weird" symbols... :-)

I cannot recall if there is already a notion of "alias" in free pascal, if not then we just introduce this idea within the scope of "with" expression.

Alternatively, how about just use SPACE to separate the token? i.e.: with SomeObject o1, SomeOtherObject o2 do....

I think this is a bad idea.
One of the strengths of Pascal is its verbosity/redundancy which allows unambiguous error messages and avoids many common mistakes. For example when I forget a comma

  with A B do

the compiler points to B and writes "DO" expected but "identifier B" found.
Using a space as separator compiles this without error.

Because you need a COMMA for 2 or more expressions in with, and SPACE is not valid in token?

Mattias

I cannot recall if there is already a notion of "alias" in free pascal, if

not then we just introduce this idea within the scope of "with" expression.

Let me give you one then:

procedure p; [public, alias: 'my_p'];

i.e.:

variable. In my feeling things un-pascal is extensive use of "weird" symbols... :-)

I cannot recall if there is already a notion of "alias" in free pascal,

if not then we just introduce this idea within the scope of "with" expression.

Which is why I suggested "absolute" as this already carries the note of "a is the same as b".

Though considering that we already have an "alias" token that would also be an alternative...

Regards,
Sven

And another one:

var
  a:integer;
  a_alias:integer absolute a;

:)

Ludo

Reading your comment, maybe "same" is a worth candidate ;-)

-Flávio

2013/3/18 leledumbo

Is it related to COM or DLL stuff? Where is this kind of usage documented in the manual?

Thanks!

Is it related to COM or DLL stuff?

No, though might be if you want to export with your own symbol in DLL

Where is this kind of usage documented in the manual?

http://www.freepascal.org/docs-html/ref/refsu64.html

I personally prefer to use tokens first that we already have and "same" is not part of them.

Regards,
Sven

I fail to see how this would be helpful.
It's just more confusing.
Suddenly there are 2 (or more?) identifiers meaning the same thing. If I want to avoid typing a long identifer name multiple times I would simply select it and copy it to the clipboard. If someone (I myself?) chose a long identifier name I think it was for some reason (readability?). Foiling this by making the code more obscure is not a good idea IMO. That's making the code a bit more C'ish (harder to read). You won't cripple down all variables to one letter names A, B, C only because this is easier to type, won't you?

+1

I don't see either why a programming language
needs to be changed to support the laziness of some programmers.

But in recent months (years?) it seems more and
more folks in here don't wont' to program in
Pascal anymore and come up all the time with "new
and improved" features that render the advantages of Pascal useless...

Ralf

Jürgen Hestermann wrote

You won't cripple down all variables to one letter names A, B, C only because this is easier to type, won't you?

You would if you'ld be programming in MUMPS ;-)

Bart

For example '@' ?

e.g.
with , , ... do

rationale:
it's sufficiently different, and as for its nominal usage, it does similar thing.

?

Best regards, Paul Ishenin

Lukasz

Al 18/03/13 04:11, En/na Paul Ishenin ha escrit:

But since "with" is only for records/objects/classes there's no possible confusion (the result of the expression being a boolean).

Bye

Hi,

Actually, this sort-of makes sense. I find "as" or something similar to be more aesthetically pleasing, but @ seems to make it clear that the identifier is just an alias (pointer address), and not a real temporary variable.

Of course I would be happy for any keyword or syntax that actually allows this to be done. Theoretically you could already use "absolute" instead, but...

Thank you,
Noah Silva

2013/3/20 Lukasz Sokol