I do not understand the overloads of the Buffer operator that require an opening or closing boundary. The overloads I am refering to are:
public static IObservable<IList<TSource>> Buffer<TSource,
TBufferClosing>(this IObservable<TSource> source,
Func<IObservable<TBufferClosing>> bufferClosingSelector)
public static IObservable<IList<TSource>> Buffer<TSource,
TBufferBoundary>(this IObservable<TSource> source,
IObservable<TBufferBoundary> bufferBoundaries)
public static IObservable<IList<TSource>> Buffer<TSource,
TBufferOpening, TBufferClosing>(this IObservable<TSource> source,
IObservable<TBufferOpening> bufferOpenings, Func<TBufferOpening,
IObservable<TBufferClosing>> bufferClosingSelector)
Could you please explain what the meaning of these boundaries is with an example?
They are equivalent to the Window operators (but each window yields IList<T> instead of IObservable<T>) that are documented here - http://introtorx.com/Content/v1.0.10621.0/17_SequencesOfCoincidence.html
I would suggest pausing and reading some of the doco that is currently out there on Rx. It is a small domain, but with lots of little concepts. The composition of these is the key to understanding it. Reading all of IntroToRx for example should take a few hours(it is only 17 pages).
Related
I am new to Doxygen but I want to use it for a technical documentation for our team.
The background: We have several services in .NET which are going to be called from a JAVA backend through RPC.
Therefore it is quite useful to have those services documented for the JAVA guys.
Using the Doxywizard did help in the first place, but it created a huge overflow of data, which I want to filter, but have no clue how to.
What I want to achieve is, that Doxygen ONLY will use methods, which does have a specific attribute.
For example:
[RpcMethod(id: "GetNumDemo", description: "A demo method")]
public async Task<int> GetNumDemo(JavaDTO dtoObject, int randNum)
I want to have the method within the documentation found by Doxygen since it has the RpcMethod attribute and also cause it have a JavaDTO object, I want to have this class documented as well.
But I am overwhelmed with it ... do you guys can help me? ... at least with a hint within the Doxygen documentation.
Read through the documentation and goodled
[I realise this is slighly off-topic for SO but I am asking this as I want to raise a couple of questions around ClearScript and I want to be able to include fiddles to make life easier.]
Is there a usable dot net playground (for example DotNetFiddle) that I can use for some fundamental learning of ClearScript, and what is a minimal bare-bones config. Ideally I would like to be able to get a link to a known-good fiddle that I can fork from. I searched for ClearScript fiddle but the few I found were incomplete or non functional. I am looking for console output only.
I tried this fiddle https://dotnetfiddle.net/rpd5le# but I do not know which Microsoft.Clearscript to reference and keep getting errors such as
Run-time exception (line 8): Inheritance security rules violated while
overriding member:
'Microsoft.ClearScript.HostItem.GetInterface(System.Guid ByRef, IntPtr
ByRef)'. Security accessibility of the overriding method must match
the security accessibility of the method being overridden.
This is the simple code I have to date:
using System;
using Microsoft.ClearScript.V8;
public class Program
{
public static void Main()
{
V8ScriptEngine engine = new V8ScriptEngine();
engine.AddHostType(typeof(Console));
Console.WriteLine("Hello from C#");
engine.Execute(#"
Console.WriteLine('Hello from Javascript');
");
}
}
Let's assume we have a function that returns a list of apples in our warehouse:
List<Apple> getApples();
After some lifetime of the application we've found a bug - in rare cases clients of this function get intoxication because some of the apples returned are not ripe yet.
However another set of clients absolutely does not care about ripeness, they use this function simply to know about all available apples.
Naive way of solving this problem would be to add the 'ripeness' member to an apple and then find all places where ripeness can cause problems and put some checks.
const auto apples = getApples();
for (const auto& apple : apples)
if (apple.isRipe())
consume(apple)
However, if we correlate this new requirement of having ripe apples with the way class interfaces are usually designed, we might find out that we need new interface which is a subset of a more generic one:
List<Apple> getRipeApples();
which basically extends the getApples() interface by filtering the ones that are not ripe.
So the questions are:
Is this correct way of thinking?
Should the old interface (getApples) remain unchanged?
How will it handle scaling if later on we figure out that some customers are allergic to red/green/yellow apples (getRipeNonRedApples)?
Are there any other alternative ways of modifying the API?
One constraint, though: how do we minimize the probability of inexperienced/inattentive developer calling getApples instead of getRipeApples? Subclass the Apple with the RipeApple? Make a downcast in the getRipeApples?
A pattern found often with Java people is the idea of versioned capabilities.
You have something like:
interface Capability ...
interface AppleDealer {
List<Apples> getApples();
}
and in order to retrieve an AppleDealer, there is some central service like
public <T> T getCapability (Class<T> type);
So your client code would be doing:
AppleDealer dealer = service.getCapability(AppleDealer.class);
When the need for another method comes up, you go:
interface AppleDealerV2 extends AppleDealer { ...
And clients that want V2, just do a `getCapability(AppleDealerV2.class) call. Those that don't care don't have to modify their code!
Please note: of course, this only works for extending interfaces. You can't use this approach neither to change signatures nor to remove methods in existing interfaces.
Regarding your question 3/4: I go with MaxZoom there, but to be precise: I would very much recommend for "flags" to be something like List<String>, or List<Integer> (for 'real' int like flags) or even Map<String, Object>. In other words: if you really don't know what kind of conditions might come over time, go for interfaces that work for everything: like one where you can give a map with "keys" and "expected values" for the different keys. If you go for pure enums there, you quickly run into similar "versioning" issues.
Alternatively: consider to allow your client to do the filtering himself, using something like; using Java8 you can think of Predicates, lambdas and all that stuff.
Example:
Predicate<Apple> applePredicate = new Predicate<Apple>() {
#Override
public boolean test(Apple a) {
return a.getColour() == AppleColor.GoldenPoisonFrogGolden;
}
};
List<Apples> myApples = dealer.getApples(applePredicate);
IMHO creating new class/method for any possible Apple combination will result in a code pollution. The situation described in your post could be gracefully handled by introducing flags parameter :
List<Apple> getApples(); // keep for backward compatibility
List<Apple> getApples(FLAGS); // use flag as a filter
Possible flags:
RED_FLAG
GREEN_FLAG
RIPE_FLAG
SWEET_FLAG
So a call like below could be possible:
List<Apple> getApples(RIPE_FLAG & RED_FLAG & SWEET_FLAG);
that will produce a list of apples that are ripe, and red-delicious.
I've compiled and weaved java and aj file.
And then I've decompiled class files to each java and aj file.
From recovered file, I can see the same number '$1$8e6adf60'.
Decompiled java
CarAspect.aspectOf().ajc$before$car_CarAspect$1$8e6adf60();
Decompiled aj
public void ajc$before$car_CarAspect$1$8e6adf60()
{
System.out.println("The car color has changed!");
}
Could you let me know what the number means?
Can I use this number to clarify the unique weaving?
Thanks for your advice in advance.
Goh.
The number after the first dollar is the advice number within the aspect. The number after the second dollar is the hashcode of the pointcut text related to the advice. For example:
public aspect Code {
before(): execution(* *(..)) {}
before(): execution(* *(..)) {}
before(): execution(* m(..)) {}
}
javap Code.class
public void ajc$before$Code$1$3444dde4();
public void ajc$before$Code$2$3444dde4();
public void ajc$before$Code$3$a6998f81();
Advice numbers 1, 2 and 3. Notice the hash codes elements for the first two advice members are the same because the pointcuts are the same.
Can I use this number to clarify the unique weaving?
Not quite sure what you mean by this, but hopefully you can work out whether you can based on my description
History of the numbers...
We (AspectJ) actually use these numbers to make incremental compilation swifter. Originally we used the 'source line' of the advice in the original aspect source file as the name suffix. That was very fragile. If you just added an empty line to the start of the file, all the generated aspect members would change name because this number changed (the line number increased). If that happened then we had to re-weave the whole system because all the calls to these guys had to be updated. We needed something more robust. So we came up with this. Using the first number means two before advices with the same pointcut text don't have names that clash. Combined with the second number we have a name that will not change if you alter the white space in your source aspect. The only thing that really changes it is if you alter the pointcut - and, of course, if you change the pointcut then we need to re-weave everything anyway as it may now match more/less than before.
How do you manage the maintenance/right format of code without problems with merge and difference hystory?
For eg. I have a very old file in repository with a wrong format like:
/**
* Old code
*/
public static void main(String[] args)
{
for (int i=0;i<10;i++) {System.out.println(i);}
}
then i format the code in:
/**
* Formatted code (ctrl-shift-f in Eclipse)
*/
public static void main(String[] args) {
for (int i = 0; i < 10000; i++) {
System.out.println(i);
}
}
If I compare this code with repository, I see a lot of change and I don't see the real difference (I change the limit 10 to 10000).
How do you manage versioning between "format code" and "activity code"?
You don't. Subversion doesn't understand programming languages or context - it just recognizes that the file changed. When you reformat the code, you'll get lots of minute changes. Your options:
Don't ever auto-format your code
Always auto-format your code, from the moment you create a new file
Deal with it.
In order to handle something like that you'll need a tool that actually understands the language. Version control systems don't include such capabilities since they're designed to be generalized and the language doesn't really matter (assuming the language is in text and not binary data).
The only such tool that I'm aware of is SemanticMerge. Which knows about C# and Java only at this point. It can be configured with your version control system to replace the built in merging.
One suggestion I'd make is don't mix formatting and functional changes. If you want to reformat do that in a separate commit from the functional change. Typically I commit these changes with a note in the commit message saying there is no functional change. This helps anyone merging it to know that nothing should behave differently with the change and any behavior changing is an error in their merging.