Skip to main content

#region like what is in C#

27 replies [Last post]
awf999
Offline
Joined: 2003-07-06
Points: 0

#region lets you specify a block of code that you can expand or collapse when using the outlining feature of the Visual Studio Code Editor.

example:

// preprocessor_region.cs
#region MyClass definition
public class MyClass
{
public static void Main()
{
}
}
#endregion

Copied from: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/h...

=========================================================

This should be a standardized notation that is IDEALLY backward compatiable.

NetBeans/Creator supports this syntax:

//
...
//

See: http://blogs.sun.com/roller/page/tor?entry=copyright_folding

While that works, I would personally something simpler.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
eyekwah2
Offline
Joined: 2010-02-25
Points: 0

Being a java programmer, I can easily see why Java should be treated as its own language and not part of some .NET language which easily integrates with any Office software or other Microsoft product. Part of the beauty of Java is being relatively detached from which operating system is being used, so long as there's a virtual machine for it.

However at the same time also being a .NET programmer, come on guys that was a harmless question. How else was he going to ask that question? "Hello, I'd like to know if there existed a feature in Java like that feature in that language which can't be named by that company by which I can't say." Java and C# are languages, not religious dieties. I think we can overcome our differences and create a common interface by which we can both derive from and agree with, no (metaphorically speaking)? :)

I personally wouldn't mind having a feature like that in Java, though don't get me wrong, Java is a beautiful woman as she is now. I'd hate to give her a boob job and plaster way too much makeup on her face just because we think pamela anderson is a beautiful woman too.

cvaughn42
Offline
Joined: 2009-10-09
Points: 0

I've done both JEE and .NET development. Initially, C# was a really well thought out language, and I've seen many features move from it to Java.

The #region statement is not an IDE command, it's in the C# language specification and it's also in most of the .NET languages with subtle variations. Between you and me, it's damn useful. There are a lot of things in C# I wouldn't want brought to the Java universe, but this helpful little feature isn't one of them. Remember, most of the cost of IT comes from maintaining code, and anything that makes it easier saves money and is worthwhile.

jwenting
Offline
Joined: 2003-12-02
Points: 0

The programmer should never have to facillitate the tool in the way he writes his code.
That's why I loathe the old versions of Netbeans and VisualAIDS Java, which did just that.

The tool should ideally anticipate what the programmer is going to do and help him do it, and at the very least never get in his way.

If the tool forces the programmer to use specific constructs or the tool won't work the tool is limiting the programmer and therefore limiting what he can achieve using that tool.
That makes the tool worse than useless.

euxx
Offline
Joined: 2003-06-10
Points: 0

> The programmer should never have to facillitate the
> tool in the way he writes his code.
> That's why I loathe the old versions of Netbeans and
> VisualAIDS Java, which did just that.

So what? It will be up to any tool to save some of its own markers in a convenient place. Convenient to the tool and to the end user. Together have been using the same idea as XDoclet and I don't see why user would care if code is generated with these markers, because he don't really have to care how to save them or not to forget to send or commit tool-specific files. More over, markers can be deleted at any time and it will only affect rendering of the UML diagram.

jwenting
Offline
Joined: 2003-12-02
Points: 0

We're talking about requiring the user to actively insert syntax the only use of which is to make their editor work correctly, and tools which prevent the user from changing generated code or worse undo manual code changes.

I've no qualms with an editor inserting some markers as long as it doesn't expect me to keep them in place and will still work correctly if those markers aren't there or aren't where it expects them to be.

For example Eclipse will insert markers to indicate to itself which Strings have been externalised or are to be ignored when externalising Strings.
You're free to remove those markers and Eclipse won't mind (it just won't know to ignore those Strings next time you tell it to externalise Strings so will again suggest them).
OTOH VAJ and previous versions of Netbeans (and maybe the current versions too) would generate reams of code and happily ignore any changes you made to that code, in fact reverting those changes to its own template without any warning at all or simply disallowing code to be changed outside marked regions it would insert.
That's a tool hampering the user, restricting the user for the sake of the tool maker having an easier time. That's counterproductive.

carmello
Offline
Joined: 2003-09-10
Points: 0

Why should things like that be in the Java language?
Next time someone may come up with a hint for cvs to ignore some things.

euxx
Offline
Joined: 2003-06-10
Points: 0

In my opinion, most of the ideas coming trough forum are reflecting the weak language features. Nobody is saying that every idea has to be implemented immediately, but it worth to discuss it giving more adequate arguments then "it is suxx and shoun't ever be mentioned here".

If you return to the original suggestion, which was about adding some semantical comments to hind code folding to hint IDE. Well, I have no clue how your IDE would guess to fold some code block inside large method, but I do know that annotations would work much better over there then anything you may do with comments.

Note again, that it has nothing todo with best OO practices, neither I'm suggesting not to follow them.

jwenting
Offline
Joined: 2003-12-02
Points: 0

No, most of the ideas voiced here are just attempts to add someone's favourite feature from another language which often has no use at all in a Java context.
Those ideas reflect peoples' lack of understanding of Java more than any area where Java is weak as the vast majority are things that are already quite possible in Java using a slightly different syntax (or at most requiring a line or two of code instead of a single command).

This case is a perfect example. An attempt to bring over someone's favourite feature of C# which in C# is only used in conjunction with a specific editor to provide functionality to that editor which many Java editors provide without the need for any changes to the code and the need for which more often than not indicates bad coding practices on the part of the programmer.

johnjps
Offline
Joined: 2010-07-01
Points: 0

> This case is a perfect example. An attempt to bring
> over someone's favourite feature of C# which in C# is
> only used in conjunction with a specific editor to
> provide functionality to that editor which many Java
> editors provide without the need for any changes to
> the code and the need for which more often than not
> indicates bad coding practices on the part of the
> programmer.

Please expound on how the use of regions indicates bad coding practice.

Also, which IDE in Java has the same functionality built in without even requiring code changes? By same functionality, I don't mean just collapsing various code constructs - suppose for instance that you want to hide your getters and setters (and only your getters and setters) so they aren't cluttering up your screen while you work on other stuff in your class. How is this done in any popular Java IDE (preferably Eclipse)?

PS: and if indeed it really is possibly, why not just answer the original question with "this is how you do it: xyz" rather than starting a flame fest? There is no excuse for that regardless of your past experience. (Rise above man, rise above!)

kcpeppe
Offline
Joined: 2003-06-15
Points: 0

Gee, why would I want to annotate my code to manually do something that I IDE does for me automatically? Seems like adding clutter to get rid of.... clutter?

euxx
Offline
Joined: 2003-06-10
Points: 0

> Gee, why would I want to annotate my code to manually
> do something that I IDE does for me automatically?

Many annotations are just hints. It is not always obvious how to treat each specific case.

panic1
Offline
Joined: 2007-11-19
Points: 0

I just gotta ask, are all java programmers a-holes like the few ppl in this thread? I'm a .net programmer and this seemed like a very legitimate question but geeeez did this guy get flamed or what?? I've never been on a .NET forum like this, and this was the very first java programming thread I've ever read. Now I have a real sour taste in my mouth about Java and the people who use it. If you don't want your language to evolve at all then fine, stay in the 90s and don't expect any new adopters. It seems to me that Microsoft took a long hard look at Java and all the complaints and made their own language that catered to developers instead of blasting them for asking a simple question.

tarbo
Offline
Joined: 2006-12-18
Points: 0

As flame-prone as this message was, I'll try to reply as politely as possible. I may fail, but I will try.

You've already answered your own question. No, not all Java programmers are unpleasant, and you know this. I regret your first encounter was in a small [url=http://www.eps.mcgill.ca/jargon/jargon.html#holy%20wars]crusade[/url], and I don't entirely approve of some answers either, but I can understand them.

First of all, the question is most certainly not a legitimate one. Asked was language support for specific IDE behaviour. The fact that the OP could not separate a development environment from a programming language speaks very poorly for the action suggested.

Secondly, Java as a language, and some of its community, has a sour history with Microsoft. You may recall J++ some time ago, which led to a number of lawsuits. Microsoft made changes to Java which made it incompatible to the base language, and then flaunted it as J++, it's own language. From this branch eventually the child called C# grew. To now have C# programmers coming over and offering how to evolve Java so that it better resembles C# leaves a bitter taste with me as it does with many others, I'm sure. And this happens very, very often.

Always remember that Microsoft works for its own store, namely the Windows family. Each of their languages typically has only one IDE, is proprietary, and thus it is easy to cope with language changes. Compare with Java, which is a cross-platform, world-wide language for which [i]every tiny change[/i] requires each and every toolkit to adapt. So language changes are not taken lightly.

Can you really blame people for wishing proposers of language changes to at least have some experience with Java? To know the difference between a language specification, a compiler, and an IDE? To simply know what they are talking about? Admittedly, some could be friendlier about it, but I hope you can see things from another perspective as well now.

If you wish a similar experience on .NET fora --or any other, for that matter-- try arguing that using a same-line bracket style is better than a new-line bracket style, i.e.:

[code].public static int Main() {
// Code
}[/code]
...rather than...
[code].public static int Main()
{
// Code
}[/code]
...and get back to us on how [i]that[/i] went. ;)

jwenting
Offline
Joined: 2003-12-02
Points: 0

And don't forget the following:
1) many of us moved to Java because of bad experience with languages, languages that people are now trying to turn Java into by adding the worst "features" of those languages to Java.
2) Java was designed to be easy to use and learn, yet most of the "proposed" "features" completely defeat that and make the language harder to use and learn for the sake of making it look more like some other language.
3) the track record Sun has when it comes to adding new "features" isn't exactly stellar. It basically does come down to implementing whatever someone proposes, the wilder and more outlandish the better, and then implementing it poorly.

So we're often hostile towards "proposed" "features" for very good reasons.

johnjps
Offline
Joined: 2010-07-01
Points: 0

That's all well and good, but nonetheless we all agree (I hope!) that not all ideas are horrendous: some things absolutely should be added. The question is what.

I use both Visual studio and Eclipse on a daily basis. Some of the new features in VS 2010 are obviously based on Eclipse (e.g. a shortcut similar to Eclipse's ctr-shift-r, for finding stuff)... I'm glad they did: it's very useful.

At the same time, VS has for years allowed very useful logical constructs such as regions or project "solutions" that I personally find very useful. I think they would be great additions to Eclipse and, as noted, they are logical constructs: if they were added, you wouldn't need to use them at all.

An example of something else I'd like but which I would agree with you on: I wish Java were not case sensitive, because intellisense is just that much faster... but that's a huge leap and could possibly require you to change your programming style... so I won't be asking for that. However, I will ask for regions and solutions, and I would expect, at worst, cordial debate.

ian_rae
Offline
Joined: 2007-08-16
Points: 0

Here's a plugin for Eclipse that does what you need.

http://www.realjenius.com/platform_support

euxx
Offline
Joined: 2003-06-10
Points: 0

This is sort of things you could use annotations for. These can be already added to class, methods and fields and we obly missing annotations for a method body. However that would be resolved if we'll get support for a named code blocks in the language. E.g.

@Folding(comment="no need to see this ugly crap", type="AlwaysHide") {
... some text for folding
}

Actually I was needed it for different reason, but it serve this purpose quite ok and also enforce block ballancing.

See my post for more details http://forums.java.net/jive/thread.jspa?threadID=988&messageID=19280#19280

jwenting
Offline
Joined: 2003-12-02
Points: 0

If you want Java to be C# why not use C# in the first place?

I'm sick of people trying to turn Java into whatever their favourite language is, especially as many of them will at the same time complain that Sun seems to be taking their ideas for language features from other languages...

euxx
Offline
Joined: 2003-06-10
Points: 0

> I'm sick of people trying to turn Java into whatever
> their favourite language is, especially as many of
> them will at the same time complain that Sun seems to
> be taking their ideas for language features from
> other languages...

I really wonder why you are not using Java 1.0... Any language should evolve, otherwise it is just dead.

kcpeppe
Offline
Joined: 2003-06-15
Points: 0

>
> I really wonder why you are not using Java 1.0... Any
> language should evolve, otherwise it is just dead.

Are you suggesting that we implement every idea that comes through this forum? What would the language do if we did that. I don't think the idea is to hault langauge evoluation. However we do need to be selective about what is accepted and what isn't. There is a fine line between language features that are disruptive and those that are helpful. Sometimes innocent language features can destabilize the usability of the language. I think that is only one criteria in which changes to the language needs to be evaluated before embarking on the change because once released into the wild, there is no chance in pulling it back.

This is not a change to the language. It is about a particular annotation that I think is increadibly ugly and unnecessary since my ide understands how to fold code for me. But I would also make this suggestion. If you NEED to fold code then I'd be willing to be that you are not following good OO practices. In code that follows good design and style practices, I rarely in fact never feel the need to fold code.

jwenting
Offline
Joined: 2003-12-02
Points: 0

well said, almost exactly my idea.

The flood of useless and worse than useless demands and requests here is sickening.
I've nothing against a well thought out growth of the language, but the incessant feature creep needs to stop especially in cases where the only reason to add something is either marketing (as in the SOAP functionality that's going into Mustang or annotations into Tiger) or "because XXXXX has it" which is the usual reason given by people in these here forums.

And that goes for multiple inheritance and operator overloading as well.
Those were left out as funcamental language paradigms. Adding them would effectively change the entire idea behind Java, at which point it would be Java no longer but C++--##

kcpeppe
Offline
Joined: 2003-06-15
Points: 0

> The flood of useless and worse than useless demands
> and requests here is sickening.

dude... chill out!!! ;)

I think that we should look at features in other languages and discuss them in terms of what Java is and isn't. In this case, what Java isn't is a way to code instructions to my IDE, its a way to code instructions to my CPU! I have trouble enough getting that part to work without complicating it to configure my IDE with it? How about a UML tool? Should we have annotations in there to configure my UML tools? If so, then which one, which annotations are useful, which ones are not? Do you even know!!!

It just seems to me that this suggestion is out of scope regarding the purpose of annotations and the purpose of Java. No need to get huffy 8^)

euxx
Offline
Joined: 2003-06-10
Points: 0

> How about a UML tool?
> Should we have annotations in there to configure my
> UML tools? If so, then which one, which annotations
> are useful, which ones are not? Do you even know!!!

By the way, code-level annotations would allow to hint UML tools that is doung roundtripping for non-class diagrams (e.g. sequence and activity). For instance, stick labels and other UML info to the code. Actually I love how it is been done for class diagrams in Together, but code-level annotations would allow to move things even further.

Note, that I'm not talking about 1st post in this thread, but rather reffer to the second post by me.

kcpeppe
Offline
Joined: 2003-06-15
Points: 0

ok, but what about the other UML tools? maybe they have their own way of doing this and maybe their annotations are different?

One other point, tools are there to work for me. I dont' work for them period! I have enough work to do. These extra things get in my way and I'm not interested in a tool that cannot do round-tripping properly.

euxx
Offline
Joined: 2003-06-10
Points: 0

> ok, but what about the other UML tools? maybe they
> have their own way of doing this and maybe their
> annotations are different?

That is the problem and it should be adressed.

> One other point, tools are there to work for me. I
> dont' work for them period! I have enough work to do.
> These extra things get in my way and I'm not
> interested in a tool that cannot do round-tripping
> properly.

Well, we have different view here. To me source code is a diagram, and that is why Together suited my needs very well. Basically it doesn't really have roundripping, but rather using source code as a store for most of the diagram details.

kcpeppe
Offline
Joined: 2003-06-15
Points: 0

> > ok, but what about the other UML tools? maybe they
> > have their own way of doing this and maybe their
> > annotations are different?
>
> That is the problem and it should be adressed.

Actually, I don't see it as a problem of the tool vendors, I see it as a strength that comes from diveristy. In that way I wouldn't want a unified set of instructions as it would be a limiting factor.
>
> > One other point, tools are there to work for me. I
> > dont' work for them period! I have enough work to
> do.
> > These extra things get in my way and I'm not
> > interested in a tool that cannot do round-tripping
> > properly.
>
> Well, we have different view here. To me source code
> is a diagram,

humm, source code can be used to generate a visual perspective of the relationships that are contained with-in it's constituant parts but, it in its self is not a diagram.

> and that is why Together suited my
> needs very well. Basically it doesn't really have
> roundripping, but rather using source code as a store
> for most of the diagram details.

I like the idea of Together. Unfortunately, the implementation has not proven to be as useful as one would have hoped it to be. Desktops do not seem to be ready for TJ just yet ;)

euxx
Offline
Joined: 2003-06-10
Points: 0

> > > ok, but what about the other UML tools? maybe
> they
> > > have their own way of doing this and maybe their
> > > annotations are different?
> >
> > That is the problem and it should be adressed.
>
> Actually, I don't see it as a problem of the tool
> vendors, I see it as a strength that comes from
> diveristy. In that way I wouldn't want a unified set
> of instructions as it would be a limiting factor.

The problem is not with the tool but rather with exchanging diagrams between different UML tools. Currently you'll have to do this from scratch for every different tool. XMI doesn't really help because it has no real connection to the source.

> > Well, we have different view here. To me source
> code
> > is a diagram,
>
> humm, source code can be used to generate a visual
> perspective of the relationships that are contained
> with-in it's constituant parts but, it in its self is
> not a diagram.

It depends. When you changed your code, wouldn't you like all diagrams to reflect the change? And vice versa...

> > and that is why Together suited my
> > needs very well. Basically it doesn't really have
> > roundripping, but rather using source code as a
> store
> > for most of the diagram details.
>
> I like the idea of Together. Unfortunately, the
> implementation has not proven to be as useful as one
> would have hoped it to be. Desktops do not seem to be
> ready for TJ just yet ;)

I've been a successfull Together user for over 7 years. Too bad they choose to make really neat tool so bloated with all these extensions.