ok, I'm probably just tired (way past my bedtime), but when namespacing part of my code just now, I ran into some trouble using @global: with @size


mov(@size(namespace_data), eax);

works fine, but when I try using @size on data outside my namespace, like for example:

mov(@size(@global:w.POINT), eax);

generates following error:
"undefined identifier (dest memory operand)"

dest memory operand is eax, which is not the cause of error, so I assume there
are parsing troubles with the @size(@global:w.POINT) part of the statement.

am I simply using the wrong syntax? or am I just really dumb and tired?

I have no problem using @global: in other statements, such as

if(eax = @global:w.WM_COMMAND) then...

only in the @size function.

I have the itching feeling that I am being very stupid here.....
Posted on 2003-06-30 17:26:18 by BinarySoup
Originally posted by BinarySoup
ok, I'm probably just tired (way past my bedtime), but when namespacing part of my code just now, I ran into some trouble using @global: with @size

Not surprising, namespace lookups are somewhat fragile in HLA.



mov(@size(namespace_data), eax);

works fine, but when I try using @size on data outside my namespace, like for example:

mov(@size(@global:w.POINT), eax);

generates following error:
"undefined identifier (dest memory operand)"


Best suggestion I can make is to pull all actual procedure declarations out of your namespace and only put @forward or @external definitions in the actual namespace section, e.g.,



program c;
#include( "stdlib.hhf" )
#include( "w.hhf" )

namespace x;
static
namespace_data:dword;

procedure a; @forward;

end x;

procedure x.a;
begin a;

mov( @size( w.POINT ), eax );
mov( eax, x.namespace_data );

end a;

begin c;

end c;




Cheers,
Randy Hyde
Posted on 2003-07-01 14:47:15 by rhyde
thanks Randy, this is a working solution that actually saves me alot of @global: typing ;)

btw, is there anyway to use nested namespaces?
Posted on 2003-07-01 15:16:44 by BinarySoup
Originally posted by BinarySoup btw, is there anyway to use nested namespaces?


No. I never saw the need for it so I never implemented it. However, if you give me a good reason, I'd be willing to consider adding it to HLA v2.0 (not really feasible to add it to v1.x; namespaces are a real kludge in v1.x and, as you can tell, the code is rather fragile).

If you really need "nested namespace", you can kind of achieve this by using a pair of classes:



type
class1:class
<static, readonly, storage, const, var, macro, and procedure declarations>
endclass;

class2:class
<static, readonly, storage, const, var, macro, and procedure declarations>
nestedclass:class1;
<static, readonly, storage, const, var, macro, and procedure declarations>
endclass;


If you don't instantiate either class, you can access the static (non-var, non-method, non-iterator) names using class2.xxxx and class2.class1.xxxx.

Mostly, this achieves what you want. The missing item is types. You can't nest type declarations inside classes. Also, keep in mind that HLL-like class to class procedures load ESI (with NULL), so this may be a problem.

Implementing nested namespaces won't be that hard in HLA v2.0 if I plan on namespaces from the start (which I obviously will). I'm not sure what their utility would be however (other than to make HLA's namespace syntax a bit more generic). Might be useful for macros that expand into a namespace, I suppose.

Another thing that would be nice in HLA v2.0 is the concept of private and public names in a class (something like what C++ provides). Haven't quite figured out how to do this in assembly language in a way that makes sense, however.
Cheers,
Randy Hyde
Posted on 2003-07-02 10:26:08 by rhyde
well, personally I would like nested namespaces for extensive program structuring, it makes it easier to group/subgroup program code and data. I'm currently working on a multi-network p2p program in my spare time, and although the networks differ vastly in implementation, with namespaces I can structure the code very similarly, the nested namespacing only improves that further. ok try to show an example of what I mean with two of the p2p networks, DirectConnect and Edonkey, parameters have been struck for sake of readability.

namespace DirectConnect
namespace Edonkey

currently my calls looks somewhat like this:

DirectConnect.HubCreate();
Edonkey.ServerCreate();
Edonkey.ClientConnect();
etc etc.

this gives a nice calling structure that is similar across all networks, but what would make it even more structured would be if I could use nested namespaces.

DirectConnect.Hub.Connect();
DirectConnect.Client.Connect();
Edonkey.Server.Create();
Edonkey.Server.Connect();
Edonkey.Client.Ask();
etc etc...

here the nested namespaces are Hub, Client, Server. granted, this has little impact on the actual code (although it allows me to re-use variable names in each nested namespace which is very nice), but it has a great impact on someone as fuzzy like me when it comes to organizing my code, implementing a call name structure etc.

a more general example would be something like:

namespace Employees
nested
Administration
Engineering
Manufacturing

allowing for calls like
Employees.Administration.CalculateSalary();
Employees.Engineering.CurrentProjects();
etc etc...

this type of function/data structuring is of course available through the use of classes, but the overhead is pretty pointless if all I want out of classes is the ability to bind functions and data together under a naming structure, which is the case here.

anyway, I'm satisfied with namespaces as they work now (although a little more stability would not go amiss), nested namespaces would be the icing on the cake so to speak, allowing me to go CRAZY in my quest for code/name/data structure, but again, making wishes is easy, implementing them is a whole other matter.

thanks again for an excellent assembler! also, I really love the syntax, it's very well thought out and consistent.
Posted on 2003-07-02 16:38:45 by BinarySoup
Okay.
I'll remove several restrictions from HLA in v2.0 including
nested namespaces, type declaration sections within classes, and
TEXT array objects. HLA v1.x has a really messed up symbol table
structure (having been kludged royally over the years) and I'll seriously
break something if I try to add nested namespaces to it. But HLA v2.0
uses a decent data structure for the symbol table so nested namespaces
are certainly possible.

Randy Hyde
Posted on 2003-07-08 16:10:13 by rhyde
well, huge thanks, really looking forward to 2.0 ;) just hope it won't be alot of extra work for you. personally it's a great boost as I find nested namespaces the perfect way to organize and localise code/data without resorting to classes. anyway, I hope that since HLA is already highly dependant on namespaces through stdlib and includes, that you were considering a overhaul of it's robustness either way, and thus adding nested namespaces isn't a totally new branch for you in your work towards HLA 2.0.

btw, I'm amazed everytime I stumble across someone like you, who works their arse off, creating excellent tools for people to use, for FREE. then helps them with every little problem they have, even when they obviously have neglected to read the manual that you have poured tons of time and effort into, and then take upon yourself even more work when backseat drivers like me remark on the lack of nested namespaces.

once again, greatest of thanks!
Posted on 2003-07-09 06:47:33 by BinarySoup
Originally posted by BinarySoup
HLA is already highly dependant on namespaces through stdlib and includes, that you were considering a overhaul of it's robustness either way, and thus adding nested namespaces isn't a totally new branch for you in your work towards HLA 2.0.

Absolutely not. The introduction of namespaces into HLA v1.x was a total hack specifically to support the standard library in a more reasonable fashion. I knew when I was first implementing the code that not supporting nested namespaces was a "less than aesthetic" solution. Alas, the design of v1.x prevented a clean implementation of namespaces (though, in retrospect, I probably should have used this as an excuse to redo the symbol table format and save myself additional headaches down the road).


btw, I'm amazed everytime I stumble across someone like you, who works their arse off, creating excellent tools for people to use, for FREE. then helps them with every little problem they have, even when they obviously have neglected to read the manual that you have poured tons of time and effort into, and then take upon yourself even more work when backseat drivers like me remark on the lack of nested namespaces.

once again, greatest of thanks!


One thing I've discovered is that it doesn't make any sense to work your tail off on some project and then not support it (via documentation and on-line support). What amazes me is that there are people out there who will put a tremendous amount of effort into a project and then tell the users that they are on their own. Some people may be happy cranking out a ton of software for their own personal use, but if I'm going to expend this kind of effort to create something, I want people to use it. And unless you support and market the software, people won't use it.
Cheers,
Randy Hyde
Posted on 2003-07-09 11:31:46 by rhyde
randall.hyde wrote:

One thing I've discovered is that it doesn't make any sense to work your tail off on some project and then not support it (via documentation and on-line support). What amazes me is that there are people out there who will put a tremendous amount of effort into a project and then tell the users that they are on their own. Some people may be happy cranking out a ton of software for their own personal use, but if I'm going to expend this kind of effort to create something, I want people to use it. And unless you support and market the software, people won't use it.


I am truly inspired by your commitment, my fears was that you'd start feeling like there is no way to keep up with the demands from the users. there is a thin line between feature requests and whining, and I just want to make sure I'm not crossing it. if it ever happens, just shout!
Posted on 2003-07-25 22:42:56 by BinarySoup