By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,760 Members | 1,630 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,760 IT Pros & Developers. It's quick & easy.

using "using" to fake typedefs

P: n/a
I am designing a package of functions to be
used by people with very little programming
experience (if any) and very little patience.

I don't want to scare them with programmerish
words like "double" and "int". I think "Number"
and "Integer" would be more palatable.

If I were writing in C/C++ I would just

typedef double Number;
typedef int Integer;

But I'm using C# because I thought it would be
"safer" for these folks.

So, how do I "typedef" in C# ??

I know I can write something like

using Number = System.Double;

But where do I put this to make it globally visible ??

I certainly don't want my users to see it at
the top of every file, so I need to hide it
somewhere.

thanks

bk

Nov 16 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a

"bubbakittee" <bu*********@cox.net> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
I am designing a package of functions to be
used by people with very little programming
experience (if any) and very little patience.

I don't want to scare them with programmerish
words like "double" and "int". I think "Number"
and "Integer" would be more palatable.

If I were writing in C/C++ I would just

typedef double Number;
typedef int Integer;

But I'm using C# because I thought it would be
"safer" for these folks.

So, how do I "typedef" in C# ??

I know I can write something like

using Number = System.Double;

But where do I put this to make it globally visible ??

I certainly don't want my users to see it at
the top of every file, so I need to hide it
somewhere.


You don't. There is no typedef equivilent in C#, nor shoudl there be.

Frankly, if the people you are writing functions for can't handle the
language, why are they using it? I suspect you would be best off using a
simpler, dynamic or scripting language rather than a general purpose
statically typed one.
Nov 16 '05 #2

P: n/a
> You don't.
There is no typedef equivilent in C#, nor shoudl there be.
OK. Thanks for the clarification.
Frankly, if the people you are writing functions for can't handle
the language, why are they using it? I suspect you would be
best off using a simpler, dynamic or scripting language rather
than a general purpose statically typed one.


Maybe you're right. I was exploring C# because it has
(1) A fabulous development environment (Vis Sudio)
(2) Lots of helpful compile-time checking
(3) Nice built-in arrays and strings
(4) Headroom. Though my prospective users are
neophytes, some of them will get excited about
programming and want to do more. I'd like them to be
able to grow without switching languages.
(5) Familiarity and presence. I can buy 20 books
at my local bookstore, get help easily, etc.
(6) Fairly simple syntax (compared to C++, anyway),
and I thought I could subset it and tart it up a bit with
some typedefs. Apparently not.

As you mentioned in another post, IronPython might
be a better answer. But it's not done yet, and I know
even less about Python than I know about C#.

Nov 16 '05 #3

P: n/a

"bubbakittee" <bu*********@cox.net> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
You don't.
There is no typedef equivilent in C#, nor shoudl there be.
OK. Thanks for the clarification.
Frankly, if the people you are writing functions for can't handle
the language, why are they using it? I suspect you would be
best off using a simpler, dynamic or scripting language rather
than a general purpose statically typed one.


Maybe you're right. I was exploring C# because it has
(1) A fabulous development environment (Vis Sudio)
(2) Lots of helpful compile-time checking
(3) Nice built-in arrays and strings
(4) Headroom. Though my prospective users are
neophytes, some of them will get excited about
programming and want to do more. I'd like them to be
able to grow without switching languages.
(5) Familiarity and presence. I can buy 20 books
at my local bookstore, get help easily, etc.


Each of these are great reasons why *you* should write in C#, but not
nessecerily your clients, ;).

Remember, .NET was geared towards multiple languages. With a little
exploration you should be able to find a language that will compile to the
..NET runtime and be simple enough to support your clients. You can have your
clients use that language and you can write your library in C# or whatever
other .NET language suits you best.

You might want to look at VB.NET, IronPython, nemerle and boo, the latter
are both functinoal languages targeting the runtime.

VB.NET has the above features and has Integer instead of int(althoug Single
and Double are still used) plus a plethora of other functions.

IronPython, nemerle, and boo are functional and a bit more dynamic. I would
probably suggest IronPython or boo, as I thought nemerle was a bit more
complex than the others, but my experiance with all of them is pretty minor.

There are other languages available as well, you might find one I havn't
thought off that fits your purposes precisely.

Or you could write your own, :-D
(6) Fairly simple syntax (compared to C++, anyway),
and I thought I could subset it and tart it up a bit with
some typedefs. Apparently not.


Typedefs no, but you could use a combonation of implicit types and custom
structures to fake it(don't quote the syntax, I'm typing directly in to the
message instead of an editor).

public struct Integer
{
public Integer(int val)
{
value = val;
}

int value;
public int Value{
get
{
return value;
}
}

public static implicit operator Integer(int input)
{
return new Integer(input);
}
public static implicit operator int(Integer input)
{
return input.Value;
}
}

You also should override .Equals and operator==, plus ToString, etc. But
that is unrelated to the concept.
I would strongly advise against it, suggesting you find another .NET
compatible language that would be more suitable to your target audience, but
in the worst case this will probably help(Sorry I didn't mention it the
first time, I forgot about it). This will work but has a greater potential
for failure
Nov 16 '05 #4

P: n/a
bubbakittee wrote:
I am designing a package of functions to be
used by people with very little programming
experience (if any) and very little patience.


I'd suggest looking at python or ruby. They are very "clean", simple and
the interactivity of the interpreter allows very rapid exploration of
the language and program behaviour.

There are pretty good editors for the languages, for example pythonwin.

C# is filled with the twists of static typing and arcane heritage af
c-syntax ("foo || bar" as opposed to "foo or bar").

(remember, while trained programmers find static typing (at least
somewhat :) natural, it took time to learn... actually for many
(including myself) it took time to unlearn before starting to use
dynamicly typed languages again :)

VB (and VB.net) are (esp. from a teaching perspective) a horrible
language in terms of cleanness, so try to escape that.

--
Helge
Nov 16 '05 #5

P: n/a
Thanks again. Your "fake" looks promising. I think I'll give it a try,
even though you advise against it. What's wrong with it ??

I have looked for other languages.

IronPython looks promising, too. I wish the guy would hurry up
and get it done.

boo and VB don't have operator overloading. The application
is 3D geometry, so I think it's very important to have 3D
vectors appear as first-class objects with all the obvious
operators overloaded.

Never heard of Nermerle. I'll take a look, but as I said,
I don't want to use something obscure (been there, done that).

Someone else suggested (in jest) that I write my own language.
In a sense, that's what I'm doing. I'm taking a small subset
of C#, adding some custom classes (geometric things like
points, curves, surfaces), and tidying it up as best I can.
Thanks again for your help.

bubbakittee

Nov 16 '05 #6

P: n/a
Daniel O'Connell [C# MVP] wrote:
"bubbakittee" <bu*********@cox.net> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

So, how do I "typedef" in C# ??

You don't. There is no typedef equivilent in C#, nor shoudl there be.


Well, I was in a scenario where I really wanted one. I develop an O/R
mapper and my Oracle SQL engine was initially written with ODP.NET. Now,
I wanted to support DataDirect's driver as well. Their OracleDbType enum
was different, for the rest almost no differences. A typedef could have
solved it. Even worse, Microsoft's Oracle provider uses a different name
for the type definition enum. A typedef could make the same code
compilable against MS' provider instantly, now I have to copy a lot of
code and surround it with #ifdef constructs which is also not that
pleasant.

Admitted, typedef opens up a lot of crappy constructs as well.

FB

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Nov 16 '05 #7

P: n/a

"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Daniel O'Connell [C# MVP] wrote:
"bubbakittee" <bu*********@cox.net> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

So, how do I "typedef" in C# ??

You don't. There is no typedef equivilent in C#, nor shoudl there be.


Well, I was in a scenario where I really wanted one. I develop an O/R
mapper and my Oracle SQL engine was initially written with ODP.NET. Now, I
wanted to support DataDirect's driver as well. Their OracleDbType enum was
different, for the rest almost no differences. A typedef could have solved
it. Even worse, Microsoft's Oracle provider uses a different name for the
type definition enum. A typedef could make the same code compilable
against MS' provider instantly, now I have to copy a lot of code and
surround it with #ifdef constructs which is also not that pleasant.


As would have a using alias, if I undersatnd the problem. If it is only a
single file, I don't see why a using alias wouldn't do what you needed...

The problem I have with typedefs is either they are

1) Nothing more than project level using aliases. This wouldn't solve the
OP's problem in general, the typedef line would still have to be *somewhere*
in the projects files.
or
2) Compiled notions in an assembly as to what types should be called.

1 allows for simplicity in some cases, yes, but I think its 2 that worries
me the most.

When you start having typedefs float around much like they do in C++, you
run the risk of some very, very ugly code indeed. IN assembly A INT == int,
in assembly B Integer == int, in assembly C INT == Integer, and in assembly
D Integer=long...

Yes, crappy constructs, :-D.
Nov 16 '05 #8

P: n/a
Well, as I read somewhere ...

The C# "using" construct is almost identical to C/C++ typedef.
But the difference is that C/C++ allows us to put our typedef
in a header file and then include that header file all over the place.
I can scatter

using Number = System.Double;
using Integer = System.Int32;

everywhere, too, but I can't bundle them both into some
sort of package to be included.

It's the "include" facility that gives us a clean way to make
a set of typedefs global.

So, we should be whining about the lack of "include", not about
the lack of "typedef".

But the "fake" outlined above seems OK to me, and whining
about the choices of the language designers doesn't do
much good, anyway.

Nov 16 '05 #9

P: n/a

"bubbakittee" <bu*********@cox.net> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...
Thanks again. Your "fake" looks promising. I think I'll give it a try,
even though you advise against it. What's wrong with it ??

Other than the potential for some small losses of functionality(for example,
when boxed, you couldn't use is int, just is Integer). The biggest risk is
vastly confusing experianced programmers. When I expect an integer, I expect
it to be typed int, not Integer, etc. There are also potential typing
errors(typeof will return Integer, not int, etc), which would cause trouble
in more advanced scenarios.

The problem is mostly hampering yourself with a model that won't grow with
its users as well as native typing will.
I have looked for other languages.

IronPython looks promising, too. I wish the guy would hurry up
and get it done.

It will take a while, the author is now working for MS and doesn't seem to
have as much time these days.
boo and VB don't have operator overloading. The application
is 3D geometry, so I think it's very important to have 3D
vectors appear as first-class objects with all the obvious
operators overloaded. Ahh, yes, operator overloading is certainly a nice thing to have in those
circumstances, ;).

Someone else suggested (in jest) that I write my own language.
In a sense, that's what I'm doing. I'm taking a small subset
of C#, adding some custom classes (geometric things like
points, curves, surfaces), and tidying it up as best I can.
Thanks again for your help.


Really it is a viable option, ;). If your application is Open Source or your
usage is otherwise compatible with the GPL, you could take the mono compiler
and modify the keywords to use Integer and Number(or whatever) and remove a
few C# features you don't want, creating your own variant of the langauge.
It'd only take a little while to do so, especially if you are already
comfortable with YACC grammars.

As long as its not linked with your library, I do not believe you have to
open your library up, just your modified compiler.

The downside, of course, is that the mono compiler doesn't always spit out
as good of error messages as the C# compiler does and you do have to work at
and maintain a compiler as well.

If its not, you'd be stuck writing your own basic language. Its not hard to
do if you are familiar with tools like YACC, but if you've never used them
the time to learn may outweigh other options.
Nov 16 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.