Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - luiscubal

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 »
1
Proposals / Re: Arrays
« on: September 16, 2012, 07:26:44 am »
Hmmm...

Code: (edl) [Select]
[x,y,z] = func()[1..3]

2
Proposals / Re: Arrays
« on: September 14, 2012, 04:48:12 pm »
Code: (edl) [Select]
[0, x] = func();

Seems to imply that the first element should be 0. Just like this:

Code: (edl) [Select]
Array res = func();
assert(res[0] == 0);
x = res[1];

3
Proposals / Re: Arrays
« on: September 14, 2012, 07:21:16 am »
Prefix, postfix. I really don't care. It was just a proposal.

For further headaches:
Code: (edl) [Select]
int& x = ...;
int& y = ...;
[ x > 2 ? x : y] = func();

(Basically, what if instead of just variables it actually allowed any reference? Non-references would still be forbidden)

4
Proposals / Re: Arrays
« on: September 13, 2012, 04:59:20 pm »
Here's my proposal.

1. If function returns a scalar, forbid [] syntax. Completely. It's worthless anyway.
2. If function returns Array, allow [] syntax but force the number of parameters to match.
3. If function returns Array but you don't want to use all parameters, use
Code: (edl) [Select]
[a, b, c, ...] = func();
Still, the array would be forced to have at least 3 elements.
4. If this is *still* not acceptable, you could have this:
Code: (edl) [Select]
[a, b?] = func();
or
Code: (edl) [Select]
[a, b=2]=func();
That code would work for func() returning both 1 or 2 parameters. It'd still be an error for 0 or more than 2 parameters (for 0, use a?. For more than 2, add the "...")
Code: (edl) [Select]
[a?, b?, ...] = func();
This is inspired by function arguments syntax.

As a final note, after an optional variable, all following variables must be optional. So this would still be an error:
Code: (edl) [Select]
[a?, b] = func(); //ERROR!

As an extra note, __unused could be used for worthless variables:
Code: (edl) [Select]
[__unused, x, __unused, __unused?, y?] = func();
cout << __unused << endl; //ERROR: __unused is not defined

If you dislike this syntax, this could also be used (although it might be more error-prone):
Code: (edl) [Select]
[, x, , ?, y?] = func();

5
Proposals / Re: Arrays
« on: September 13, 2012, 02:43:34 pm »
Agree with
Code: (edl) [Select]
[x, y] = array_func();

Disagree with
Code: (edl) [Select]
[x, y] = scalar_func();

6
Proposals / Re: Named loops vs numbered breaks
« on: September 13, 2012, 01:48:45 pm »
Well:

Code: (edl) [Select]
z_loop: for (int z = 0; z < 100; ++z) {
   y_loop: for (int y = 0; y < 100; ++y) {
      x_loop: for (int x = 0; x < 100; ++x) {
          break z_loop;
      }
   }
}
and
Code: (edl) [Select]
instance_loop: foreach (auto instance : instances) {
     adjacent_instances_loop: foreach (auto adjacent : instance.adjacent_instances()) {
         break instance_loop;
     }
}
Seems pretty clear to me.
Frankly, I'd generally avoid using integers for anything that can be reasonably named, but whatever.

Just remember: more features mean more test cases.

And regarding test cases, don't forget to add mixed loops/switch cases to your test suite.

7
Proposals / Re: Resource group load/save functions
« on: September 13, 2012, 12:27:50 pm »
I approve this concept. I've even thought about implementing this concept multiple times in my own game projects (although IIRC the idea never went ahead)

However, I'd change the API:
Code: (edl) [Select]
resource_group_id_t resource_group_load(string group_name);
void resource_group_unload(resource_group_id_t id);

resource_group_load_request_t resource_group_load_thread(string group_name);

//Wait for the loading to be finished.
resource_group_id_t request_group_thread_join(resource_group_load_request_t request_id);

//Tries to join, but does not hang if the loading is not done. Useful for loading screens.
bool request_group_thread_try_join(resource_group_load_request_t request_id, resource_group_id_t& group_id);

Feel free to change the type names (I just used these so the meaning would be easier to understand).

If a OO-style API is acceptable, then this could be further changed.

8
Proposals / Re: Named loops vs numbered breaks
« on: September 13, 2012, 12:19:53 pm »
Yet one more reason to avoid numbered breaks: Some people might expect "start at 0" while others will expect "start at 1".

9
Proposals / Re: Named loops vs numbered breaks
« on: September 11, 2012, 04:05:25 pm »
I voted named loops because it's less confusing, more intuitive and less error-prone.
Besides, it's the way Java does it so there are already precedents showing it can work.

Regarding the "error prone" part, imagine if you replaced that if case with a switch case. Then you'd have to change "break 2" to "break 3". Would you remember? That would be a pretty messy bug to track down. With named loops, there is no such problem.

Regarding warnings to "break 1". Why even allow it in the first place? Just ban it with a compile error. Problem solved. One less horrible feature to test.

The question to ask about "numbered breaks" is not "can we add it easily?", which I have no doubt you can if you can also do named loops. The real question is "what would this improve?". I can not think of any situation where numbered breaks would beat named breaks.

BTW: Just call the loop "outer_loop: for(...)"

10
Announcements / Re: k done
« on: July 21, 2012, 10:04:59 pm »
Quote
TGMG has a massive testing platform running on it
Can't(in fact, shouldn't) you port it to other platforms too? I mean, wouldn't this testing platform also help finding platform-specific bugs that would otherwise not be found (since an OS X-only testing suite can't find Windows/Linux bugs)

11
Announcements / Re: wtf am I doing
« on: July 18, 2012, 08:18:16 am »
Instead of running ENIGMA through Java, can't you just directly run the commands via command line (thus bypassing Java<->Valgrind interaction nightmares?)
Aside from that, you can always turn on all warning-related flags you can find.

If the file isn't too big, you can do things the classic gdb way. Jump into, Jump Into, Jump Out, etc.

12
Announcements / Re: Das Newspost
« on: July 12, 2012, 07:22:16 pm »
Ah. In what way is this related to the JustDefineIt project? Also, is this C++-only or does this include the EDL language extensions(or whatever you call them)?

13
Announcements / Re: Das Newspost
« on: July 12, 2012, 09:11:24 am »
So what are the main differences between this new parser and the previous ones?

14
Announcements / Re: New members
« on: March 24, 2012, 10:35:58 am »
"Name a yellow fruit: "
I hope this accepts "apple" because yellow apples do exist.

15
Announcements / Re: Why does it look like nothing's happening?
« on: March 07, 2012, 01:08:40 pm »
"deleting spree". Doesn't git(and SVN, for that matter) keep a history that pretty much makes this sort of thing fixable in less than 5 minutes?

Couldn't you just go pick the previous versions of the deleted files on git (or your old SVN, if Rusky somehow broke git that badly), then add the missing files back to git so people who checked out git directly would have a working copy?

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 »