Messages

If the consensus is to push back the autoptr declarations then I won't keep pressing it for now, but I think the compiler will need a way to see the instances as not being pointers.

Gurok, do you mean you can now have nested user pointers within a user type with access modifiers within the same script in which the first struct is defined? I'll test this afternoon. Probably do some more extensive testing on my changes as well.

Yes. That's exactly what I meant. Sorry, it was confusing even as I was typing it out.

I started looking into constructors tonight. I think the return after parsing a "new" statement should become conditional (e.g. if constructor, don't return, just keep running the rest of parse_sub_expr). We will also have to adjust the way functions are interpreted to allow them to see constructors. It's a little awkward, but I think safer than duplicating or refactoring that block of code.

CW, do you think we should do the locking down with "builtin" as a separate commit? I could see that hitting files many times, especially agsdefns.sh.

Also, CW, if you give me another patch, I guess I could rebase the branch. Getting good at this Git thing.

Crimson Wizard, I followed your instructions and fixed the branch (check the commit history now!):

https://github.com/gurok/ags/tree/331_new_user_struct

monkey_05_06, I think I fixed that autoptr managed struct example with a contained autoptr struct.

Am I right in assuming that allowing zero-byte dynamic user structs will be an engine change, CW? If so, do we just add another commit for the engine?

LOVE 2D
It uses Lua (warning: has great power). It runs on a variety of platforms and people are writing some nice libraries for it that can do some of the grunt work for you.

NodeWebkit
If you really want to write Javascript, you could probably make a game with this. It has some shortcomings, but you can also leverage a lot of Node libraries. I had some troubles developing an engine in it, but I believe if you stick to canvas (which I didn't), it's quite good.

Both of those options would probably require you to build most of the underlying platform game engine yourself. :/ I can't think of anything more 2D platform related that I'd recommend.

Also, both of my recommendations are pretty much bring-your-own-IDE. For me, that's commonly a text editor like TextPad or Notepad++ with rudimentary compiler integration.

I agree with you, CW. I've felt a little paralysed by the discussion going on here. I really don't want to put any changes that would break scripts into 3.3.1. I want to go back to a *simpler* plan for now:
- new operator (done)
- keyword "builtin" to lock down any operations we don't want (creating new objects, extending, etc.)
- fix bugs (somewhat done, zero-sized structs should probably be tolerated)
- constructors (even this is iffy right now)

Save the overhaul for 3.4 or even 3.5. I think we shouldn't worry about needing to remove "builtin" in the future. The rule should be: anything that doesn't get a syntax highlight isn't officially supported, and just leave it at that.

Can you override Say and have dialogs use it correctly?

No, because dialogs do not call "Say" via script API, obviously, they call program functions directly.

If functions are implemented in such a way, AFAICT they're allowed but they just get ignored. The engine's implementation still gets called. Are you seeing different behaviour, CW?

Actually I do.
I typed "player.ChangeRoom(0)", and "bla" was displayed instead of room change.

Oh right. I was testing Say, naturally.

Code: ags

function Character::Say(const string message, ...)
{
	Display("Here's the message: %s", message);
}

If functions are implemented in such a way, AFAICT they're allowed but they just get ignored. The engine's implementation still gets called. Are you seeing different behaviour, CW?

When it's not inside quotes, a statement only ends in AGS when you place a semicolon after it. Something like this is valid AGS script:

Code: ags

int
x
;
x
=
0
;
while
(
x
<
10
)
x++
;

Moreover, new lines are treated just like they're spaces. If you need to space things out, any whitespace will do

Hey! Abstract doesn't mean someone can't create an instance for you. It just means you can't directly construct it.

I believe monkey_05_06 was suggesting to use static only for classes it applies to (i.e. those with all-static members). This makes sense, I guess, but I don't think it's 100% necessary.

CW has it right. Internal is to keep a property within the assembly it was declared in. If we had a property that meant "you can't construct this and can't use the keyword extends on it", I would prefer "builtin".

Regarding structs and the point of them v/s managed structs, I think it's actually a good way to ease people into the concept of objects. As CW said, there are no nulls. It's a very safe place to play.

This doesn't solve the problem of another class extending a built-in class though.

It would if you made the class sealed/final.

Yeah, I'm more and more convinced that what's needed is a notion of horizontal scope, an access modifier that doesn't depend on class structure but on the location of the code, like "internal" in C# or the default/package scope in Java.

Yeah, sorry, Snarky. I edited that. I meant to say using extender methods. If you use an extender method, you have that protected scope and so could call the constructor.

I can code up "internal" or "builtin". It's no problem. I just thought the two-word combo had more utility.

It wouldn't be possible to simply limit the scope of the constructor (and make the class sealed/final), so it can be accessed by the engine but not the user script (cf. Java package scope)?

Actually, I thought about having protected constructors for the built-in types. This doesn't solve the problem of another class using extender methods on a built-in class though.

Sorry for the double post.

Edit: "internal" might be used by C# so, semi-standard.

Hrmm... abstract classes can't be instantiated directly (e.g. new Character()). There's no rule about never having an instance of one. The idea here is that the user sees the abstract class (Character) and the engine is providing a phony implementing class that it constructs.

[E]

Given the many additions to the language specification, I suggest you keep a list of those changes either in the original post or a separate wiki page so it's easier to go through the final result.

We keep a list of changes in the form of Git history . I used that for preparing change list for 3.3.0.

"abstract" could be used to prevent people from instantiating your struct directly (only through derived structs). The engine would be exempt from this rule, of course.

I don't know... this will look weird. "Abstract" means something not real... its like using word "interface" for something what is not.
E: On other hand, it is a class which is implemented in the engine, and not in script, which means that its implementation is separate. So... okay.

I was working from this http://msdn.microsoft.com/en-us/library/sf985hc5.aspx

I think "abstract" on structs would allow us to optionally have abstract methods down the track.

If you don't like "abstract", I think "builtin" is the next best suggestion. Static only works for things like Game. Character could not have a static modifier, because technically there are instances, just not user-creatable ones.

This swag culture nothing but pure crap. It's ruining class. It has stopped producing classy people. I hate it.

I tip my fedora to you, Adeel.

Should we also use this keyword to prevent people from creating structs that extend built-in types? Right now (3.3.0) it's possible to do:

Code: ags

struct ExtendedCharacter extends Character
{
}

which gives you a struct where every instance maps to character[0].

If I had to choose one your suggestions, CW, I would go with "builtin". "internalstring" is already a modifier, so "internal" seems bad.

But...

I was thinking we could do this with two struct keywords, "abstract" and "sealed".

"abstract" could be used to prevent people from instantiating your struct directly (only through derived structs). The engine would be exempt from this rule, of course.

"sealed" would prevent the extends keyword from being used. Extender methods would still be allowed, making the term "sealed" a little shaky, but I think they're pretty good fits.

I know you don't typically see "abstract sealed" in the wild, but there's also typically no completely inaccessible object construction like this. MSDN says that abstract and sealed can't be combined in C# because they're contradictory. That's not entirely true when they're used as modifiers for a class. They would just result in relatively useless classes (normally).

> Cast "know all of your magic" on the wizard, take his robe and dump him in the moat

May you please make separate commits for changes in Engine and Compiler? Because they are, in fact, separate programs.
That patch I made could work as a commit on its own. It will even bear my name on it .
(if something will go wrong everyone will know who is responsible )

While testing, I made a pointer to a test struct with two ints and the size of its type was 8. I believe this should be 4. 8 is correct for the size when calling SCMD_NEWUSEROBJECT, but in all the cases I saw, it looked like pointers were always 4.

I think you are confusing the size of struct and size of "pointer" (managed handle)?

Oh right, yes, I'll fix up the commits soon. Sorry. I would actually be happy if you made a branch and I sent you patches to fix things.

Yes, maybe you're right. I just had a look at some of the other managed types (Character *, Object *) and they seem to report their struct's size too.

Well, I created a cleaned up branch for it:

https://github.com/gurok/ags/tree/331_new_user_struct

Just a minor tidy up and monkey_05_06, your example should now compile. Not sure if the way I've fixed the bug is correct though. Going to possibly revise it in the future.

It relates to forward declarations. They don't know the size of themselves. That's fine, but all pointer declarations should have a size of 4.

While testing, I made a pointer to a test struct with two ints and the size of its type was 8 (or 0 at the time of declaration). 8 is correct for the size when calling SCMD_NEWUSEROBJECT, but not the size of the pointer. It looks like we need an if() statement to see whether it's a pointer somewhere and change its size accordingly. I'll have to investigate.

You should now be able to create an array of your managed struct too.

I haven't implemented constructors, but I'll be adding them after I fully investigate this pointer issue. And possibly clean up some other areas.

I think BASIC's going to feature pretty prominently in the answers here. I started with TRS-BASIC on a Tandy TRS-80 Model III. I was mucking around with it at age 4 then about a year later, I was programming. I was in love with the idea of modular programming. I would write games that spanned multiple diskettes just so my game could say "insert disk 2". I thought it was all very professional. Looking back, programming was like playing a game. I think I was about 7 or 8 when I finally got an HGA. Still a floppy system, but I had MS-DOS 2.1. From there, I moved up through the MS BASICs (GW-BASIC->QBASIC->VisualBASIC) and finally studied C/C++/Java at university. Now I do web/UI work in JS all day :/.

Whoa

One more TODO... I was going to change the compiler to allow structs to have functions with the same name, e.g.

Code: ags

managed struct MyStruct
{
  import function MyStruct(int a, int b);
}

It's a simple patch, replace "(towrite != in_struct_declr)) {" in cs_parser.cpp with "(towrite != in_struct_declr || sym.stype[last_time] == SYM_VARTYPE)) {"

And the "MyStruct" function would act as a constructor, e.g. x = new MyStruct(3, 4);

Then it's just a matter of parsing a function call after each new statement is parsed.

I'll have a look at your new Editor patch before I start on a proper branch, CW. This is so cool.

If you've seen the part where it parses an array, I think that's the right place to put the managed struct stuff too. It's just a matter of having an if() statement like...

If the symbol following the var symbol is not "["
  ... managed struct creation code ...
else
  ... dynamic array creation code ...
end if

Anyway, really exciting! Awesome work, CW.

EDIT: Saved games (serialisation/deserialisation) would be one of the first things I'd like to test. Anyway, I'll get to work on this, sorry!

1. jwalt
2. AprilSkies
3. Ghost