What I'm trying to achieve:
I have a public method in a class that I would like to be removed from autocompletion in IDEs by making it private via YARD.
I've tried adding #api private, #!visibility private, #private and it doesn't seem to make any difference - IDE in documentation popups clearly shows this method is still public, and it is still available to be auto-completed.
Why not just make this method a true private one?
I'm trying to achieve full backward compatibility for existing users. It's a public gem.
The goal is better UX for end users by removing unnecessary methods from being listed in auto-completion.
IDEs affected: RubyMine(2021.1), Emacs/LSP(Solagraph backend).. probably Visual Studio Code as well.
So, the question is "Does RubyMine/LSP ignore YARD #private #!visibility private settings?" or is it something with my local setup?
Related
I would like to use Confirm Prompt but currently Confirm Prompt supports only few languages such as en-us, fr-fr etc. I would like to use Confirm Prompt for 2 different languages which are not supported by default. I know I can use fields as confirmChoices and choiceOptions to manually specify confirm choices but that would mean that I have to create 1 ConfirmPrompt for every language which is not included in Confirm Prompt by default.
The easiest way to add support for more languages, which are not included by default, would be to add them to defaultChoiceOptions map. But this map is declared as private static, hence it can not be modified.
So I am thinking about extending ConfirmPrompt class and overriding onPrompt and onRecognize method which will be exactly same as in ConfirmPrompt class but it will use myCustomDefaultChoiceOptions which will be non static and public field in my custom class => problem solved.
But this is hackish solution and I can not understand why this map is not public and non static in Bot Framework SDK.
Hence I am asking, is there any other solution (natively supported by framework) which allows me to add support for different languages in ConfirmPrompt?
This was actually a change pushed out a couple of months ago (by me). You'll need to update your packages.
choiceDefaults is private (and non-static, now), however, it can be updated by passing it into the constructor.
The easiest/best way to do this would be to build your PromptCultureModel for each language/locale/culture (so you can also use it easily with ChoicePrompt), then create the object with those PromptCultureModels that matches ChoiceDefaultsConfirmPrompt, and then pass that into the constructor.
You can see how I did this in it's test here.
Note: When you overwrite choiceDefaults, you lose all of the currently-supported languages. You can easily add them to your PromptCultureModel object via PromptCultureModels.getSupportedCultures().
Note: I've got a to-do to add some additional languages, but it's on the backlog since you can now add your own.
I have a huge library of classes I copied and I want to set all methods in all classes to:
throw new NotImplementedException();
Does ReSharper have a way to do this globally over the whole solution?
You can do this using ReSharper's Search with Pattern feature in semi-automatic way, i would say. I'll better attach screenshot.
This way you replace all private instance methods in Solution. Then you need to replace all public, protected, internal, same with static and virtual keywords and you'll be there.
The first point in the Semantic Versioning Specification states that compatible software must declare a public API.
I'm wondering how gems establish this public API. It seems that it's typically done through the readme (see ActiveRecord, for example), which doesn't feel like it draws a strict boundary between the public API code and the rest. An example of a gem that does this better is the Twitter API, placing its public API code in an API directory, but even there the line is grey, as the public API's configure method is defined in twitter.rb, outside the API directory.
As a potential contributor to a gem that attempts to stick to semantic versioning (which is most of them, given we have tools like bundler), I'd like to know which methods are part of the public API, and which aren't. Maybe I have to look through more source code, but are there guidelines somewhere for clearly defining your public API?
There are some popular ways to define the public API. Which one you choose is mostly a matter of taste.
One way is documentation. You simply state in the documentation, which protocols are part of the public API, and what the contract of those protocols is. YARD even has predefined tags for this.
Another way is testing. I think Merb did this. The public API was described in its RSpec tests. The private parts were obviously also tested, but those tests lived in a different directory.
This is actually pretty cool, because it allows you to tie together code changes and semantic version changes: everytime you add a test to the public directory you need to bump the minor version. Everytime you delete or modify a test in the public directory you need to bump the major version.
Or the other way round: you are not allowed to change or delete tests during a minor revision.
I have to write a lot of helper classes for some reasons like below:
//original class
public class Class1{
public Class1(int p1,int p2){}
}
public class Class2{
public Class2(int p3,int p4,int p5){}
}
//helper class
public static Helper{
public static Class1(int p1,int p2){}
public static Class2(int p3,int p4,int p5){}
}
I need auto generate these helpers at design time, so I think I need a tools require these feature:
Template write at design time.
Template varible can base on the exists classes in source codes at design time(means they are not compilered to Assembly).
Can be auto generate when the source codes(classed) changed or then file saved.
Is there any tools like that?
BTW: Is there any tools can query classes at design time? like I want find classes that is not sealed when they dont have subclasses.
You may want to consider Roslyn. I rewrote classes before using Roslyn, but only as an experiment, to inject attributes in the class. To make it work, I had to write a console application because Visual Studio 2010 didn't allow easy integration at the time. Since the code didn't change much, it wasn't a problem to run manually.
You may be able to adapt it for your scenario.
Maybe this helps (the T4 templates) ?
http://msdn.microsoft.com/en-us/library/bb126445.aspx
Or there is a purely manual way to use the reflection
http://www.codeproject.com/Articles/19513/Dynamic-But-Fast-The-Tale-of-Three-Monkeys-A-Wolf
But I bet this is not the way you really want it.
I was looking at the ruby mixin blog post, and it says that when a module is included in a class its self.included() method is called.
My question is, where is this behaviour officially documented? I can't seem to locate it on the ruby-docs.org website or the pickaxe.
While it's not on Ruby Doc for some reason, included actually is documented. Running ri Module.included in the terminal provides this:
included( othermod )
Callback invoked whenever the receiver is included in another module
or class. This should be used in preference to Module.append_features
if your code wants to perform some action when a module is included in
another.
module A
def A.included(mod)
puts "#{self} included in #{mod}"
end
end
module Enumerable
include A
end
This documentation can be found in the Ruby source in object.c. Sadly, Module.extended is not documented.
I suspect it's not on the RubyDoc website because it's a private method, and private methods aren't currently displayed.
People are aware of this issue, but they haven't yet worked out how to handle methods that are private even though they aren't implementation details.
I've created a bug report at http://bugs.ruby-lang.org/issues/6381
seems only public methods are documented
Both are documented on page 556 of the second edition of pickaxe (covering Ruby 1.8). The documentation there looks just like the result of ri Module.included that Andrew Marshall posted, so I suspect that section of the book was automatically generated. If it's been dropped from later editions of pickaxe, then it might be a result of the same bug that keeps it from showing up on ruby-doc.org.